På fredag 17. juni 2016 kl. 08:14:39, skrev Amit Kapila mailto:amit.kapil...@gmail.com>>:
On Fri, Jun 17, 2016 at 11:39 AM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På torsdag 16. juni 2016 kl. 20:19:44,
skrev Tom Lane mailto:t...@sss.pgh.pa.us>>:
Amit Kapila mailto:amit.kap...@ente
On Fri, Jun 17, 2016 at 11:39 AM, Andreas Joseph Krogh
wrote:
> På torsdag 16. juni 2016 kl. 20:19:44, skrev Tom Lane :
>
> Amit Kapila writes:
> > On Mon, Jun 13, 2016 at 10:36 PM, Tom Lane wrote:
> >> min_parallel_relation_size, or min_parallelizable_relation_size, or
> >> something like that
På torsdag 16. juni 2016 kl. 20:19:44, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>:
Amit Kapila writes:
> On Mon, Jun 13, 2016 at 10:36 PM, Tom Lane wrote:
>> min_parallel_relation_size, or min_parallelizable_relation_size, or
>> something like that?
> You are right that such a variable will
On 16 June 2016 at 00:40, Jimmy wrote:
>
> (1) I can (and do) use psql, pg_isready seems lighter and since it already
> supports credentials and DB name, I see very little harm for pg_isready
> to say back whether user logged IN or not using these credentials.
>
>
> (2) timeout is not the same -
On 17 June 2016 at 08:34, Greg Stark wrote:
> So we would release 10.0.0 and 10.0.1 and the next major release would be
> 11.0.0.
>
> This would have two benefits:
>
> 1) It emphasises that minor releases continue to be safe minor updates
> that offer the same stability guarantees. Users would be
On 15 June 2016 at 06:48, David G. Johnston
wrote:
>
> We could stand to be more explicit here. The docs for version()
> indicated the server_version_num should be used for "machine processing".
>
> The implied correct way to access the canonical server version is thus:
>
> SELECT current_sett
Hi,
On 06/16/2016 01:00 AM, Tom Lane wrote:
Tomas Vondra writes:
Attached is a reworked patch, mostly following the new design proposal
from this thread.
I've whacked this around quite a bit and am now reasonably happy with it.
The issue of planning speed hit should be pretty much gone, alth
Alvaro Herrera wrote:
> Andrew Gierth wrote:
> > Why is the correct rule not "check for and ignore pre-upgrade mxids
> > before even trying to fetch members"?
>
> I propose something like the attached patch, which implements that idea.
Hm, this doesn't apply cleanly to 9.4. I'll need to come up
On Fri, Jun 17, 2016 at 3:20 AM, Robert Haas wrote:
>
> On Thu, Jun 16, 2016 at 12:16 PM, Robert Haas
wrote:
> > On Thu, Jun 16, 2016 at 8:00 AM, Amit Kapila
wrote:
> >>> 1. The case originally reported by Thomas Munro still fails. To fix
> >>> that, we probably need to apply scanjoin_target to
On Wed, Jun 15, 2016 at 08:56:52AM -0400, Robert Haas wrote:
> On Wed, Jun 15, 2016 at 2:41 AM, Thomas Munro
> wrote:
> > I spent some time chasing down the exact circumstances. I suspect
> > that there may be an interlocking problem in heap_update. Using the
> > line numbers from cae1c788 [1],
Amit Kapila writes:
> On Thu, Jun 16, 2016 at 11:49 PM, Tom Lane wrote:
>> But you need to include to use INT_MAX ...
> I wonder why it has not given me any compilation error/warning. I have
> tried it on both Windows and CentOS, before sending the patch.
Some platforms seem to make it availa
Andrew Gierth wrote:
> But that leaves an obvious third issue: it's all very well to ignore the
> pre-upgrade (pre-9.3) mxid if it's older than the cutoff or it's in the
> future, but what if it's actually inside the currently valid range?
> Looking it up as though it were a valid mxid in that cas
On Thu, Jun 16, 2016 at 11:49 PM, Tom Lane wrote:
>
> Amit Kapila writes:
> > On Mon, Jun 13, 2016 at 10:36 PM, Tom Lane wrote:
> >> min_parallel_relation_size, or min_parallelizable_relation_size, or
> >> something like that?
>
> > You are right that such a variable will make it simpler to writ
On 2016/06/16 22:00, Robert Haas wrote:
On Thu, Jun 16, 2016 at 7:05 AM, Etsuro Fujita
wrote:
ISTM that a robuster solution to this is to push down the ft1-ft2-ft3 join
with the PHV by extending deparseExplicitTargetList() and/or something else
so that we can send the remote query like:
select
Robert Haas writes:
> On Thu, Jun 16, 2016 at 6:40 PM, Tom Lane wrote:
>> Meh. I think this is probably telling us that trying to repurpose Aggref
>> as the representation of a partial aggregate may have been mistaken.
> I don't mind if you feel the need to refactor this.
I'm not sure yet. Wh
On Thu, Jun 16, 2016 at 6:40 PM, Tom Lane wrote:
> Meh. I think this is probably telling us that trying to repurpose Aggref
> as the representation of a partial aggregate may have been mistaken.
> Or maybe just that fix_combine_agg_expr was a bad idea. It seems likely
> to me that that could hav
On 15 Jun 2016 2:59 pm, "David G. Johnston"
wrote:
>
> IIRC the plan is to have the machine version behave as if the middle
number is present and always zero. It would be (the?) one place that the
historical behavior remains visible but it is impossible to have a totally
clean break.
I haven't b
Robert Haas writes:
> On Thu, Jun 16, 2016 at 4:31 PM, Tom Lane wrote:
>> However, before trying to fix any of that, I'd like to demand an
>> explanation as to why aggoutputtype exists at all. It seems incredibly
>> confusing to have both that and aggtype, and certainly the code comments
>> give
On Thu, Jun 16, 2016 at 4:51 PM, Vik Fearing wrote:
> On 10/06/16 17:01, Robert Haas wrote:
>> Update pg_stat_statements extension for parallel query.
>
> I couldn't readily find a review for this patch, and I am unsatisfied
> with it. I think it's very strange that a 1.4 version would call a
> f
On Thu, Jun 16, 2016 at 4:31 PM, Tom Lane wrote:
> However, before trying to fix any of that, I'd like to demand an
> explanation as to why aggoutputtype exists at all. It seems incredibly
> confusing to have both that and aggtype, and certainly the code comments
> give no hint of what the semant
On Thu, Jun 16, 2016 at 12:16 PM, Robert Haas wrote:
> On Thu, Jun 16, 2016 at 8:00 AM, Amit Kapila wrote:
>>> 1. The case originally reported by Thomas Munro still fails. To fix
>>> that, we probably need to apply scanjoin_target to each partial path.
>>> But we can only do that if it's paralle
Tom Lane-2 wrote
> The problem with an extension is: when we make a core change that breaks
> one of these views, which we will, how can you pg_upgrade a database
> with the extension installed? There's no provision for upgrading an
> extension concurrently with the core upgrade. Maybe there shou
I believe I've narrowed down the cause of this failure [1]:
regression=# explain SELECT min(col) FROM enumtest;
ERROR: type matched to anyenum is not an enum type: anyenum
The core reason for this seems to be that apply_partialaggref_adjustment
fails to consider the possibility that it's dealing
On 16/06/16 20:31, Jim Nasby wrote:
> On 6/13/16 12:16 PM, Tom Lane wrote:
>> At the same time, I'm pretty suspicious of putting stuff like this in
>> core, because the expectations for cross-version compatibility go up
>> by orders of magnitude as soon as we do that.
>
> On a first go-round, I do
2016-06-16 20:31 GMT+02:00 Jim Nasby :
> On 6/13/16 12:16 PM, Tom Lane wrote:
>
>> At the same time, I'm pretty suspicious of putting stuff like this in
>> core, because the expectations for cross-version compatibility go up
>> by orders of magnitude as soon as we do that.
>>
>
> On a first go-rou
On 2016-06-16 11:57:48 -0700, Andres Freund wrote:
> See
> https://www.postgresql.org/message-id/20160616183207.wygoktoplycdz...@alap3.anar
For posterity's sake, that was supposed to be
https://www.postgresql.org/message-id/20160616183207.wygoktoplycdz...@alap3.anarazel.de
--
Sent via pgsql-ha
On 2016-06-16 13:53:01 -0500, Kevin Grittner wrote:
> On Thu, Jun 16, 2016 at 1:19 PM, Kevin Grittner wrote:
> > On Thu, Jun 16, 2016 at 11:54 AM, Andres Freund wrote:
> >> On 2016-06-16 12:43:34 -0400, Robert Haas wrote:
>
> >>> Maybe it would help if you lay out the whole sequence of events, l
On Thu, Jun 16, 2016 at 1:32 PM, Andres Freund wrote:
> With old_snapshot_threshold=1 I indeed can reproduce the issue. I
> disabled autovacuum, to make the scheduling more predictable. But it
> should "work" just as well with autovacuum.
>
> S1: CREATE TABLE toasted(largecol text);
> INSERT
On Thu, Jun 16, 2016 at 1:19 PM, Kevin Grittner wrote:
> On Thu, Jun 16, 2016 at 11:54 AM, Andres Freund wrote:
>> On 2016-06-16 12:43:34 -0400, Robert Haas wrote:
>>> Maybe it would help if you lay out the whole sequence of events, like:
>>>
>>> S1: Does this.
>>> S2: Does that.
>>> S1: Now doe
Hi,
On 2016-06-16 13:19:13 -0500, Kevin Grittner wrote:
> On Thu, Jun 16, 2016 at 11:54 AM, Andres Freund wrote:
> > On 2016-06-16 12:43:34 -0400, Robert Haas wrote:
>
> >> The root of my confusion is: if we prune a tuple, we'll bump the page
> >> LSN, so any session that is still referencing th
On 6/13/16 12:16 PM, Tom Lane wrote:
At the same time, I'm pretty suspicious of putting stuff like this in
core, because the expectations for cross-version compatibility go up
by orders of magnitude as soon as we do that.
On a first go-round, I don't think we should add entire views, but
rathe
On 2016-06-16 13:16:35 -0500, Kevin Grittner wrote:
> On Thu, Jun 16, 2016 at 1:01 PM, Andres Freund wrote:
>
> > The relevant part is the HeapTupleSatisfiesMVCC check, we're using
> > SatisfiesToast for toast lookups.
> >
> > FWIW, I just tried to reproduce this with old_snapshot_threshold = 0 -
Amit Kapila writes:
> On Mon, Jun 13, 2016 at 10:36 PM, Tom Lane wrote:
>> min_parallel_relation_size, or min_parallelizable_relation_size, or
>> something like that?
> You are right that such a variable will make it simpler to write tests for
> parallel query. I have implemented such a guc and
On Thu, Jun 16, 2016 at 11:54 AM, Andres Freund wrote:
> On 2016-06-16 12:43:34 -0400, Robert Haas wrote:
>> The root of my confusion is: if we prune a tuple, we'll bump the page
>> LSN, so any session that is still referencing that tuple will error
>> out as soon as it touches the page on which
On Thu, Jun 16, 2016 at 1:01 PM, Andres Freund wrote:
> The relevant part is the HeapTupleSatisfiesMVCC check, we're using
> SatisfiesToast for toast lookups.
>
> FWIW, I just tried to reproduce this with old_snapshot_threshold = 0 -
> but ran into the problem that I couldn't get it to vacuum any
As of HEAD you can exercise quite a lot of parallel query behavior
by running the regression tests with these settings applied:
force_parallel_mode = regress
max_parallel_workers_per_gather = 2-- this is default at the moment
min_parallel_relation_size = 0
parallel_setup_cost = 0
parallel_tupl
On 2016-06-16 13:44:34 -0400, Robert Haas wrote:
> On Thu, Jun 16, 2016 at 12:54 PM, Andres Freund wrote:
> >> The root of my confusion is: if we prune a tuple, we'll bump the page
> >> LSN, so any session that is still referencing that tuple will error
> >> out as soon as it touches the page on w
Hi,
2016-06-16 9:48 GMT-03:00 Michael Paquier :
> On Thu, Jun 16, 2016 at 8:37 PM, Martín Marqués
> wrote:
>> El 16/06/16 a las 00:08, Michael Paquier escribió:
>>> On Wed, Jun 15, 2016 at 7:19 PM, Martín Marqués
>>> wrote:
How would the recovery process work? We expect the schema to
On Thu, Jun 16, 2016 at 12:54 PM, Andres Freund wrote:
>> The root of my confusion is: if we prune a tuple, we'll bump the page
>> LSN, so any session that is still referencing that tuple will error
>> out as soon as it touches the page on which that tuple used to exist.
>
> Right. On the main tab
On Thu, Jun 16, 2016 at 12:50 PM, Tom Lane wrote:
> Amit Kapila writes:
>> On Thu, Jun 16, 2016 at 9:26 AM, Robert Haas wrote:
>>> 3. In https://www.postgresql.org/message-id/25521.1465837...@sss.pgh.pa.us
>>> Tom proposed adding a GUC to set the minimum relation size required
>>> for considerat
On 2016-06-16 12:43:34 -0400, Robert Haas wrote:
> On Thu, Jun 16, 2016 at 12:14 PM, Andres Freund wrote:
> >> > The issue isn't there without the feature, because we (should) never
> >> > access a tuple/detoast a column when it's invisible enough for the
> >> > corresponding toast tuple to be vac
Amit Kapila writes:
> On Thu, Jun 16, 2016 at 9:26 AM, Robert Haas wrote:
>> 3. In https://www.postgresql.org/message-id/25521.1465837...@sss.pgh.pa.us
>> Tom proposed adding a GUC to set the minimum relation size required
>> for consideration of parallelism.
> I have posted a patch for this upt
On Thu, Jun 16, 2016 at 12:14 PM, Andres Freund wrote:
>> > The issue isn't there without the feature, because we (should) never
>> > access a tuple/detoast a column when it's invisible enough for the
>> > corresponding toast tuple to be vacuumed away. But with
>> > old_snapshot_timeout that's obv
Teodor Sigaev writes:
>> So I think there's a reasonable case for decreeing that should only
>> match lexemes *exactly* N apart. If we did that, we would no longer have
>> the misbehavior that Jean-Pierre is complaining about, and we'd not need
>> to argue about whether <0> needs to be treated s
On Thu, Jun 16, 2016 at 8:00 AM, Amit Kapila wrote:
>> 1. The case originally reported by Thomas Munro still fails. To fix
>> that, we probably need to apply scanjoin_target to each partial path.
>> But we can only do that if it's parallel-safe. It seems like what we
>> want is something like th
On 2016-06-16 12:02:39 -0400, Robert Haas wrote:
> On Thu, Jun 16, 2016 at 11:37 AM, Andres Freund wrote:
> >> If that were really true, why would we not have the problem in
> >> current production versions that the toast table could be vacuumed
> >> before the heap, leading to exactly the issue y
On Thu, Jun 16, 2016 at 11:37 AM, Andres Freund wrote:
>> If that were really true, why would we not have the problem in
>> current production versions that the toast table could be vacuumed
>> before the heap, leading to exactly the issue you are talking
>> about?
>
> The issue isn't there withou
Michael Paquier writes:
> On Wed, Jun 15, 2016 at 10:34 PM, Tom Lane wrote:
>> My feeling is that we'd keep
>> the pg_attribute.attnotnull field and continue to drive actual enforcement
>> off that, but it would just reflect a summary of the pg_constraint state.
> OK, I see. Hm, by storing this
On 2016-06-16 09:50:09 -0500, Kevin Grittner wrote:
> On Wed, Jun 15, 2016 at 8:57 PM, Andres Freund wrote:
>
> > The simplest version of the scenario I'm concerned about is that a tuple
> > in a tuple is *not* vacuumed, even though it's elegible to be removed
> > due to STO. If that tuple has to
On Thu, Jun 16, 2016 at 10:03 PM, Robert Haas wrote:
> On Thu, Jun 16, 2016 at 2:33 AM, Masahiko Sawada
> wrote:
>> Option name DISABLE_PAGE_SKIPPING is good to me.
>> I'm still working on this, but here are some review comments.
>>
>> ---
>> +CREATE FUNCTION pg_truncate_visibility_map(regclass)
On Wed, Jun 15, 2016 at 8:57 PM, Andres Freund wrote:
> The simplest version of the scenario I'm concerned about is that a tuple
> in a tuple is *not* vacuumed, even though it's elegible to be removed
> due to STO. If that tuple has toasted columns, it could be the that the
> toast table was inde
On Thu, Jun 16, 2016 at 4:35 PM, Euler Taveira wrote:
> On 16-06-2016 09:05, Magnus Hagander wrote:
> > Shouldn't pg_upgrade turn off vacuum cost delay when it vacuums the new
> > cluster? Not talking about the post-analyze script, but when it runs
> > vacuumdb to analyze and freeze before loadin
On 16-06-2016 09:05, Magnus Hagander wrote:
> Shouldn't pg_upgrade turn off vacuum cost delay when it vacuums the new
> cluster? Not talking about the post-analyze script, but when it runs
> vacuumdb to analyze and freeze before loading the new schema, in
> prepare_new_cluster()? Those run during d
On 01-06-2016 20:52, Andreas Karlsson wrote:
> I think at least three of the four aggregate functions are little used,
> so I do not think many users would be affected. And only min(citext) and
> max(citext) can make use of the parallel aggregation.
>
> The functions are:
>
> min(citext)
> max(ci
On 06/14/2016 09:55 PM, Robert Haas wrote:
On Tue, Jun 14, 2016 at 1:51 PM, Robert Haas wrote:
On Tue, Jun 14, 2016 at 6:37 AM, Andreas Karlsson wrote:
I have rebased all my patches on the current master now (and skipped the
extensions I previously listed).
Thanks, this is really helpful.
El 16/06/16 a las 09:48, Michael Paquier escribió:
> On Thu, Jun 16, 2016 at 8:37 PM, Martín Marqués
> wrote:
>
>> This problem came up due to a difference between pg_dump on 9.1.12 and
>> 9.1.22 (I believe it was due to a patch on pg_dump that excluded the
>> dependent objects from being dumped
On Thu, Jun 16, 2016 at 2:33 AM, Masahiko Sawada wrote:
> Option name DISABLE_PAGE_SKIPPING is good to me.
> I'm still working on this, but here are some review comments.
>
> ---
> +CREATE FUNCTION pg_truncate_visibility_map(regclass)
> +RETURNS void
> +AS 'MODULE_PATHNAME', 'pg_truncate_visibilit
On Thu, Jun 16, 2016 at 7:05 AM, Etsuro Fujita
wrote:
> ISTM that a robuster solution to this is to push down the ft1-ft2-ft3 join
> with the PHV by extending deparseExplicitTargetList() and/or something else
> so that we can send the remote query like:
>
> select ft1.a, (ft3.a IS NOT NULL) from (
On Thu, Jun 16, 2016 at 8:37 PM, Martín Marqués wrote:
> El 16/06/16 a las 00:08, Michael Paquier escribió:
>> On Wed, Jun 15, 2016 at 7:19 PM, Martín Marqués
>> wrote:
>>>
>>> How would the recovery process work? We expect the schema to be there
>>> when restoring the tables?
>>
>> pg_dump crea
Shouldn't pg_upgrade turn off vacuum cost delay when it vacuums the new
cluster? Not talking about the post-analyze script, but when it runs
vacuumdb to analyze and freeze before loading the new schema, in
prepare_new_cluster()? Those run during downtime, so it seems like you'd
want those to run as
On Thu, Jun 16, 2016 at 9:26 AM, Robert Haas wrote:
>
> On Tue, Jun 14, 2016 at 12:18 PM, Tom Lane wrote:
> > Amit Kapila writes:
> >> On Mon, Jun 13, 2016 at 9:37 PM, Tom Lane wrote:
> >>> ... I got a core dump in the window.sql test:
> >>> which I think may be another manifestation of the
fa
El 16/06/16 a las 00:08, Michael Paquier escribió:
> On Wed, Jun 15, 2016 at 7:19 PM, Martín Marqués
> wrote:
>>
>> How would the recovery process work? We expect the schema to be there
>> when restoring the tables?
>
> pg_dump creates the schema first via the CREATE EXTENSION command,
> then ta
On 2016/06/15 9:13, Amit Langote wrote:
On 2016/06/15 0:50, Robert Haas wrote:
On Tue, Jun 14, 2016 at 4:06 AM, Amit Langote wrote:
Attached new version of the patch with following changes:
OK, I committed this version with some cosmetic changes.
Thank you all for working on this!
While r
> "Alvaro" == Alvaro Herrera writes:
Alvaro> I think that was a good choice in general so that
Alvaro> possibly-data-eating bugs could be reported, but there's a
Alvaro> problem in the specific case of tuples carried over by
Alvaro> pg_upgrade whose Multixact is "further in the future" co
On Thu, Jun 16, 2016 at 10:39 AM, Jakob Egger wrote:
> Hi!
>
> I've looked at the way libpq handles TLS certificates and plaintext
> fallback, and I am somewhat surprised.
>
> The default ssmode is prefer. According to the documentation, this will
> make libpq use an SSL connection if possible, b
Hi!
I've looked at the way libpq handles TLS certificates and plaintext fallback,
and I am somewhat surprised.
The default ssmode is prefer. According to the documentation, this will make
libpq use an SSL connection if possible, but will use a plain text connection
as a fallback. The certifica
On Tue, May 10, 2016 at 5:39 PM, Amit Kapila
wrote:
>
>
> Incomplete Splits
> --
> Incomplete splits can be completed either by vacuum or insert as both
> needs exclusive lock on bucket. If vacuum finds split-in-progress flag on
> a bucket then it will complete the split o
67 matches
Mail list logo
