Re: [HACKERS] Potential hot-standby bug around xacts committed but in xl_running_xacts

On 1 May 2017 at 22:38, Andres Freund wrote: > The thread below > http://archives.postgresql.org/message-id/f37e975c-908f-858e-707f-058d3b1eb214%402ndquadrant.com > describes an issue in logical decoding that arises because > xl_running_xacts' contents aren't necessarily

Re: [HACKERS] Transition tables for triggers on foreign tables and views

On Fri, Apr 28, 2017 at 05:07:31AM +, Noah Misch wrote: > On Wed, Apr 26, 2017 at 11:17:05AM +1200, Thomas Munro wrote: > > My colleague Prabhat Sahu reported off list that transition tables > > don't work for views. I probably should have thought about that when > > I fixed something similar

Re: [HACKERS] vcregress support for single TAP tests

On Mon, May 1, 2017 at 11:01 PM, Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote: > > > In the absence of further comments I'm going to apply this and > back-patch it so we can get a significant improvement in how the > buildfarm reports results from TAP tests, as well as increased

Re: [HACKERS] snapbuild woes

On Mon, May 01, 2017 at 12:32:07PM -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-05-01 08:46:47 -0400, Tom Lane wrote: > >> 30sec is kind of a big lump from a buildfarm standpoint, especially if > >> you mean "it runs for 30s on my honkin' fast workstation". I'm

Re: [HACKERS] logical replication and PANIC during shutdown checkpoint in publisher

On Tue, May 2, 2017 at 7:07 AM, Peter Eisentraut wrote: > On 4/25/17 21:47, Michael Paquier wrote: >> Attached is an updated patch to reflect that. > > I edited this a bit, here is a new version. Thanks, looks fine for me. > A variant approach would be to

Re: [HACKERS] subscription worker doesn't start immediately on eabled

On 4/26/17 11:51, Fujii Masao wrote: > On Wed, Apr 26, 2017 at 4:03 PM, Kyotaro HORIGUCHI > wrote: >> At Tue, 25 Apr 2017 14:45:03 -0400, Peter Eisentraut >> wrote in >> <3d6a1bd0-08ce-301d-3336-ec9f623a3...@2ndquadrant.com>

Re: [HACKERS] subscription worker doesn't start immediately on eabled

On 4/27/17 21:36, Masahiko Sawada wrote: > That makes sense to me. Since NOCONNECT option changes some default > values including ENABLED to false I think we should apply it also when > NOCONNECT is specified? That's not necessary, because if NOCONNECT is specified, then "enabled" will be set

Re: [HACKERS] Small patch for pg_basebackup argument parsing

On Sat, Apr 22, 2017 at 12:46 PM, Pierre Ducroquet wrote: >> Here are the general guidelines about patch submission: >> https://wiki.postgresql.org/wiki/Submitting_a_Patch >> And the best thing would be to register it to the next commit fest so >> as it does not get lost: >>

Re: [HACKERS] CTE inlining

On 1 May 2017 at 21:05, Tomas Vondra wrote: > On 05/01/2017 06:22 AM, Pavel Stehule wrote: >> >> >> >> 2017-05-01 1:21 GMT+02:00 Andres Freund > >: >> >> On 2017-04-30 07:19:21 +0200, Pavel Stehule wrote: >> >

Re: [HACKERS] CTE inlining

On Sun, Apr 30, 2017 at 5:54 PM, Tomas Vondra wrote: > But I keep running into people who face serious performance issues exactly > because not realizing this, and using CTEs as named subqueries. And when I > tell them "optimization fence" they react "Whaaat?" >

Re: [HACKERS] CTE inlining

On 1 May 2017 at 22:26, Andreas Karlsson wrote: > I am not sure I like decorators since this means adding an ad hoc query hint > directly into the SQL syntax which is something which I requires serious > consideration. And mangling the semantics of existing syntax doesn't?

Re: [HACKERS] A design for amcheck heapam verification

On Mon, May 1, 2017 at 9:20 PM, Tom Lane wrote: > ISTM if you want to do that you have an inherent race condition. > That is, no matter what you do, the moment after you look the currently > oldest open transaction could commit, allowing some other session's > view of

Re: [HACKERS] Logical replication in the same cluster

On 4/30/17 20:31, Andres Freund wrote: > On 2017-04-26 23:41:51 +0200, Petr Jelinek wrote: >> Yes that's result of how logical replication slots work, the transaction >> that needs to finish is your transaction. It can be worked around by >> creating the slot manually via the SQL interface for

Re: [HACKERS] A design for amcheck heapam verification

On Mon, May 1, 2017 at 6:20 PM, Tom Lane wrote: > Maybe you can fix this by assuming that your own session's advertised xmin > is a safe upper bound on everybody else's RecentGlobalXmin. But I'm not > sure if that rule does what you want. That's what you might ultimately

Re: [HACKERS] A design for amcheck heapam verification

Peter Geoghegan writes: > If it's not clear what I mean: existing code that cares about > RecentGlobalXmin is using it as a *conservative* point before which > every snapshot sees every transaction as committed/aborted (and > therefore nobody can care if that other backend hot

Re: [HACKERS] A design for amcheck heapam verification

On Mon, May 1, 2017 at 4:28 PM, Peter Geoghegan wrote: > Anyone have an opinion on any of this? Offhand, I think that calling > GetOldestXmin() once per index when its "amcheck whole index scan" > finishes would be safe, and yet provide appreciably better test > coverage than only

Re: [HACKERS] A design for amcheck heapam verification

On Mon, May 1, 2017 at 2:10 PM, Peter Geoghegan wrote: > Actually, I guess amcheck would need to use its own scan's snapshot > xmin instead. This is true because it cares about visibility in a way > that's "backwards" relative to existing code that tests something > against

Re: [HACKERS] CTE inlining

  30.04.2017, 08:58, "Craig Ringer" :  On 30 Apr. 2017 13:28, "Andres Freund" wrote:On 2017-04-30 00:28:46 -0400, Tom Lane wrote:> There's already a pretty large hill to climb here in the way of> breaking peoples' expectations about CTEs being

Re: [HACKERS] Description of create_singleton_array()

On Tue, May 2, 2017 at 5:47 AM, Tom Lane wrote: > > > Well, now that we've been burnt once by the specific call site moving, > I think we should learn from experience and not have this say where > it's called from. That's a lousy substitute for defining the API >

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

Amit, * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: > Sorry about the delay. No worries, I'm just back from being in NY and will take a look at this tomorrow (wrt the open item, I'll provide a status tomorrow). Thanks! Stephen signature.asc Description: Digital signature

Re: [HACKERS] snapbuild woes

On 5/1/17 13:02, Tom Lane wrote: > Andres Freund writes: >> On 2017-05-01 12:32:07 -0400, Tom Lane wrote: >>> But quite aside from the question of whether we can afford the cycles, >>> it seems like the wrong approach. IMO the buildfarm is mainly for >>> verifying

Re: [HACKERS] logical replication and PANIC during shutdown checkpoint in publisher

On 4/25/17 21:47, Michael Paquier wrote: > Attached is an updated patch to reflect that. I edited this a bit, here is a new version. A variant approach would be to prohibit *all* new commands after entering the "stopping" state, just let running commands run. That way we don't have to pick

Re: [HACKERS] A design for amcheck heapam verification

On 1 May 2017 at 20:46, Robert Haas wrote: > One problem is that Bloom filters assume you can get > n independent hash functions for a given value, which we have not got. > That problem would need to be solved somehow. If you only have one > hash function, the size of the

Re: [HACKERS] Logical replication in the same cluster

On 1 May 2017 at 19:24, Andres Freund wrote: >> There is no inherent reason why the CREATE INDEX CONCURRENTLY style of >> using multiple transactions makes it necessary to leave a mess behind >> in the event of an error or hard crash. Is someone going to get around >> to

Re: [HACKERS] A design for amcheck heapam verification

On Fri, Apr 28, 2017 at 6:02 PM, Peter Geoghegan wrote: > - Is committed, and committed before RecentGlobalXmin. Actually, I guess amcheck would need to use its own scan's snapshot xmin instead. This is true because it cares about visibility in a way that's "backwards" relative to

[HACKERS] Faster pg_timezone_names view

I've been casting about for low-hanging fruit for making the regression tests run faster. One thing I noticed is that this query in sysviews.sql is one of the slowest queries in the whole suite: select count(distinct utc_offset) >= 24 as ok from pg_timezone_names; Reading pg_timezone_names

Re: [HACKERS] A design for amcheck heapam verification

On Mon, May 1, 2017 at 12:46 PM, Robert Haas wrote: > Bloom filters are one of those things that come up on this mailing > list incredibly frequently but rarely get used in committed code; thus > far, contrib/bloom is the only example we've got, and not for lack of > other

[HACKERS] Potential hot-standby bug around xacts committed but in xl_running_xacts

Hi, The thread below http://archives.postgresql.org/message-id/f37e975c-908f-858e-707f-058d3b1eb214%402ndquadrant.com describes an issue in logical decoding that arises because xl_running_xacts' contents aren't necessarily coherent with the contents of the WAL, because RecordTransactionCommit()

Re: [HACKERS] PQhost may return socket dir for network connection

On Mon, May 1, 2017 at 1:36 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, May 1, 2017 at 12:06 PM, Tom Lane wrote: >>> Having said that, the behavior stated in $subject does sound wrong. > >> I'm not sure. My understanding

Re: [HACKERS] Description of create_singleton_array()

Neha Khatri writes: > Is it intentional to have the existing $SUBJECT. > The commit 33f43725 > > updated > the function

Re: [HACKERS] A design for amcheck heapam verification

On Fri, Apr 28, 2017 at 9:02 PM, Peter Geoghegan wrote: > I'd like to hear feedback on the general idea, and what the > user-visible interface ought to look like. The non-deterministic false > negatives may need to be considered by the user visible interface, > which is the main

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 2017-05-01 21:19, Mikael Kjellström wrote: Thanks. Will try it out. Just wanted to report that I've tried it and it works as expected. Thanks for the really fast fixes. /Mikael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 2017-05-01 21:10, Andrew Dunstan wrote: Not sure I understand what "rerun a branch" from scratch means. If you zap the branch directory you lose all its state. That's generally a bad thing. I mean like the first time when you set up the buildfarm client / branch. And it's not something I

Re: [HACKERS] snapbuild woes

On 2017-05-01 11:09:44 +0200, Petr Jelinek wrote: > On 01/05/17 10:03, Andres Freund wrote: > > On 2017-05-01 03:54:49 +0200, Petr Jelinek wrote: > >> But, I still think we need to restart the tracking after new > >> xl_running_xacts. Reason for that is afaics any of the catalog snapshots > >>

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 05/01/2017 03:00 PM, Mikael Kjellström wrote: > > On 2017-05-01 20:56, Andrew Dunstan wrote: >> OK, coming up with a more comprehensive fix. > > Ok. > >> The obvious workaround for now is to create the directory and dont zap >> it or its parents. You should only have to do it once (per

Re: [HACKERS] Logical replication in the same cluster

On Mon, May 1, 2017 at 11:37 AM, Andres Freund wrote: > What exactly are you proposing to do? You mean catching errors in the > creating backend, if it didn't crash? That is what I meant, though I'm not actually proposing to do anything. > That doesn't strike me as a good >

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 2017-05-01 20:56, Andrew Dunstan wrote: OK, coming up with a more comprehensive fix. Ok. The obvious workaround for now is to create the directory and dont zap it or its parents. You should only have to do it once (per branch) Yes, I know. That is what I have been doing so far. But

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 05/01/2017 02:46 PM, Mikael Kjellström wrote: > > > On 2017-05-01 20:44, Mikael Kjellström wrote: >> Nope, that didn't do it. > > Or well. It fixed the check_make bug but not the other bug with that > the loach.lastrun-logs-directory isn't created before trying to write > to it. > OK,

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 2017-05-01 20:44, Mikael Kjellström wrote: Nope, that didn't do it. Or well. It fixed the check_make bug but not the other bug with that the loach.lastrun-logs-directory isn't created before trying to write to it. /Mikael -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 2017-05-01 20:25, Andrew Dunstan wrote: OK, that's a bug. Mea culpa. the quick fix is this patch: diff --git a/run_build.pl b/run_build.pl index aeb8966..822b4de 100755 --- a/run_build.pl +++ b/run_build.pl @@ -1008,7 +1008,8 @@ sub writelog sub check_make

Re: [HACKERS] Logical replication in the same cluster

On 2017-05-01 11:31:53 -0700, Peter Geoghegan wrote: > On Mon, May 1, 2017 at 11:24 AM, Andres Freund wrote: > > Doing catalog changes in recovery is frought with problems. Essentially > > requires starting one worker per database, before allowing access. > > Do you think

Re: [HACKERS] Logical replication in the same cluster

On Mon, May 1, 2017 at 11:24 AM, Andres Freund wrote: > Doing catalog changes in recovery is frought with problems. Essentially > requires starting one worker per database, before allowing access. Do you think it's worth just covering the case where you get an error, such as

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 05/01/2017 02:13 PM, Mikael Kjellström wrote: > On 2017-04-19 15:59, Andrew Dunstan wrote: > > >> I have released version 4.19 of the PostgreSQL Buildfarm client. It can >> be downloaded from >> >> > > I don't know if

Re: [HACKERS] Logical replication in the same cluster

On 2017-05-01 11:22:47 -0700, Peter Geoghegan wrote: > On Fri, Apr 28, 2017 at 9:28 AM, Robert Haas wrote: > > On Thu, Apr 27, 2017 at 4:08 AM, Petr Jelinek > > wrote: > >> Back when writing the original patch set, I was also playing with the

Re: [HACKERS] Logical replication in the same cluster

On Fri, Apr 28, 2017 at 9:28 AM, Robert Haas wrote: > On Thu, Apr 27, 2017 at 4:08 AM, Petr Jelinek > wrote: >> Back when writing the original patch set, I was also playing with the >> idea of having CREATE SUBSCRIPTION do multiple committed

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 05/01/2017 02:13 PM, Mikael Kjellström wrote: > On 2017-04-19 15:59, Andrew Dunstan wrote: > > >> I have released version 4.19 of the PostgreSQL Buildfarm client. It can >> be downloaded from >> >> > > I don't know if

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 2017-04-19 15:59, Andrew Dunstan wrote: I have released version 4.19 of the PostgreSQL Buildfarm client. It can be downloaded from I don't know if it's only me or if others have noticed this also but I have the

Re: [HACKERS] Re: logical replication and PANIC during shutdown checkpoint in publisher

On 4/30/17 20:52, Noah Misch wrote: > IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 10 open item is long past due > for your status update. Please thoroughly reacquaint yourself with the policy > on open item ownership[1] and then reply immediately. If I do not hear from > you by 2017-05-02

Re: [HACKERS] PQhost may return socket dir for network connection

Robert Haas writes: > On Mon, May 1, 2017 at 12:06 PM, Tom Lane wrote: >> Having said that, the behavior stated in $subject does sound wrong. > I'm not sure. My understanding of the relationship between host and > hostaddr is that hostaddr overrides

Re: [HACKERS] Bug with pg_basebackup and 'shared' tablespace

On Friday, April 7, 2017 3:12:58 AM CEST, Kyotaro HORIGUCHI wrote: Hi, Pierre. Maybe you're the winner:p At Thu, 06 Apr 2017 12:34:09 +0200, Pierre Ducroquet wrote in <1714428.BHRm6e8A2D@peanuts2> On Thursday, April 6, 2017 2:00:55 PM CEST Kyotaro HORIGUCHI wrote: ...

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Mon, May 1, 2017 at 11:53 AM, Robert Haas wrote: > On Mon, May 1, 2017 at 12:10 PM, Kevin Grittner wrote: >> On Mon, May 1, 2017 at 10:01 AM, Robert Haas wrote: >>> It seems pretty clear to me that this is busted. >> >> I don't

Re: [HACKERS] PQhost may return socket dir for network connection

On Mon, May 1, 2017 at 12:06 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Apr 28, 2017 at 3:43 AM, Kyotaro HORIGUCHI >> wrote: >>> As the subject, PQhost() seems to be forgeting about the case >>> where only

Re: [HACKERS] snapbuild woes

Andres Freund writes: > On 2017-05-01 12:32:07 -0400, Tom Lane wrote: >> But quite aside from the question of whether we can afford the cycles, >> it seems like the wrong approach. IMO the buildfarm is mainly for >> verifying portability, not for trying to prove that

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Mon, May 1, 2017 at 12:10 PM, Kevin Grittner wrote: > On Mon, May 1, 2017 at 10:01 AM, Robert Haas wrote: >> It seems pretty clear to me that this is busted. > > I don't think you actually tested anything that is dependent on any > of my patches

Re: [HACKERS] snapbuild woes

On 2017-05-01 12:32:07 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-05-01 08:46:47 -0400, Tom Lane wrote: > >> 30sec is kind of a big lump from a buildfarm standpoint, especially if > >> you mean "it runs for 30s on my honkin' fast workstation". I'm fine > >>

Re: [HACKERS] snapbuild woes

Andres Freund writes: > On 2017-05-01 08:46:47 -0400, Tom Lane wrote: >> 30sec is kind of a big lump from a buildfarm standpoint, especially if >> you mean "it runs for 30s on my honkin' fast workstation". I'm fine >> with individual tests that run for ~ 1sec. > I was more

[HACKERS] pg_ctl wait exit code (was Re: [COMMITTERS] pgsql: Additional tests for subtransactions in recovery)

On 4/27/17 08:41, Michael Paquier wrote: > +$node_slave->promote; > +$node_slave->poll_query_until('postgres', > + "SELECT NOT pg_is_in_recovery()") > + or die "Timed out while waiting for promotion of standby"; > > This reminds me that we should really switch PostgresNode::promote to > use

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Mon, May 1, 2017 at 10:01 AM, Robert Haas wrote: > It seems pretty clear to me that this is busted. I don't think you actually tested anything that is dependent on any of my patches there. > Adding this as an open item. Kevin? It will take some time to establish

Re: [HACKERS] snapbuild woes

On 2017-05-01 08:46:47 -0400, Tom Lane wrote: > Noah Misch writes: > > On Fri, Apr 21, 2017 at 10:34:58PM -0700, Andres Freund wrote: > >> ... I was wondering about adding > >> a loop that simply runs for like 30s and then quits or such, but who > >> knows. > > > If the

Re: [HACKERS] PQhost may return socket dir for network connection

Robert Haas writes: > On Fri, Apr 28, 2017 at 3:43 AM, Kyotaro HORIGUCHI > wrote: >> As the subject, PQhost() seems to be forgeting about the case >> where only hostaddr is specified in a connection string. > I suspect that may have been

Re: [HACKERS] scram and \password

On Thu, Apr 27, 2017 at 3:22 AM, Heikki Linnakangas wrote: > You could argue, that since we need to document how to avoid the query and > the blocking, we might as well always require the application to run the > "show password_encryption" query before calling

Re: [HACKERS] Cached plans and statement generalization

On Fri, Apr 28, 2017 at 6:01 AM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > Any comments and suggestions for future improvement of this patch are > welcome. > +PG_TRY(); +{ +query = parse_analyze_varparams(parse_tree, +

Re: [HACKERS] .pgpass's behavior has changed

On Fri, Apr 28, 2017 at 3:54 AM, Kyotaro HORIGUCHI wrote: > But the above also leaves a bug so I sent another patch to fix > it. The attched patch restores the 9.6's beavior of looking up > .pgpass file in the same manner to the aother patch. Thanks for catching

Re: [HACKERS] PQhost may return socket dir for network connection

On Fri, Apr 28, 2017 at 3:43 AM, Kyotaro HORIGUCHI wrote: > As the subject, PQhost() seems to be forgeting about the case > where only hostaddr is specified in a connection string. I suspect that may have been intentional. -- Robert Haas EnterpriseDB:

Re: [HACKERS] CTE inlining

On 05/01/2017 10:17 AM, David Fetter wrote: > On Mon, May 01, 2017 at 09:22:42AM -0400, Andrew Dunstan wrote: >>> So no more planner-affecting GUCs, please, particularly if we expect >>> regular users to use them. >> +1 >> >> I still see users wanting to use the enable_foo settings in

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Mon, May 1, 2017 at 12:51 AM, Amit Langote wrote: > What we could document now is that partitioned tables don't allow > specifying triggers that reference transition tables. Although, I am > wondering where this note really belongs - the partitioning chapter,

Re: [HACKERS] CTE inlining

On Mon, May 1, 2017 at 7:43 AM, Andreas Karlsson wrote: > On 05/01/2017 04:33 PM, David G. Johnston wrote: > > On Mon, May 1, 2017 at 7:26 AM, Andreas Karlsson > I am not sure I like decorators since this means adding an ad hoc > > query hint

Re: [HACKERS] CTE inlining

On Mon, May 1, 2017 at 10:26 AM, Andreas Karlsson wrote: > What about WITH MATERIALIZED, borrowing from the MySQL terminology > "materialized subquery"? +1, you beat me to it.

Re: [HACKERS] some review comments on logical rep code

On 4/29/17 00:33, Noah Misch wrote: > On Fri, Apr 28, 2017 at 02:13:48PM -0400, Peter Eisentraut wrote: >> On 4/28/17 01:01, Noah Misch wrote: >>> On Fri, Apr 28, 2017 at 01:55:48PM +0900, Masahiko Sawada wrote: On Fri, Apr 28, 2017 at 1:42 PM, Noah Misch wrote: > On

Re: [HACKERS] CTE inlining

On 05/01/2017 04:33 PM, David G. Johnston wrote: > On Mon, May 1, 2017 at 7:26 AM, Andreas Karlsson I am not sure I like decorators since this means adding an ad hoc > query hint directly into the SQL syntax which is something which I > requires serious

Re: [HACKERS] some review comments on logical rep code

I have committed this version. I have omitted all the talk about 2PC. There are discussions ongoing about changing the transaction behavior of CREATE SUBSCRIPTION, which might interfere with that. If someone wants to rebase and propose the parts about 2PC separately, I don't object, but it can

Re: [HACKERS] Partition-wise aggregation/grouping

On Fri, Apr 28, 2017 at 3:03 AM, Antonin Houska wrote: > I think this is not generic enough because the result of the Append plan can > be joined to another relation. As such a join can duplicate the > already-aggregated values, the aggregates should not be finalized below the >

Re: [HACKERS] CTE inlining

On Mon, May 1, 2017 at 7:26 AM, Andreas Karlsson wrote: > On 05/01/2017 04:17 PM, David Fetter wrote: > >> Maybe we could allow a "decorator" that would tell the planner the CTE >>> could be inlined? >>> >>> WITH INLINE mycte AS ( ...) >>> >> >> +1 for a decorator, -1 for

Re: [HACKERS] CTE inlining

On 05/01/2017 04:17 PM, David Fetter wrote: Maybe we could allow a "decorator" that would tell the planner the CTE could be inlined? WITH INLINE mycte AS ( ...) +1 for a decorator, -1 for this one. I am not sure I like decorators since this means adding an ad hoc query hint directly

Re: [HACKERS] PG 10 release notes

On Mon, Apr 24, 2017 at 11:37 PM, Bruce Momjian wrote: >> I think that might also be because you skipped a few things that should >> get their own entries. I've not yet made a pass through your draft (and >> won't for some days), but a quick search shows the draft to e.g miss:

Re: [HACKERS] CTE inlining

On Mon, May 01, 2017 at 09:22:42AM -0400, Andrew Dunstan wrote: > > So no more planner-affecting GUCs, please, particularly if we expect > > regular users to use them. > > +1 > > I still see users wanting to use the enable_foo settings in production. > > Having had years of telling users that

[HACKERS] Description of create_singleton_array()

Is it intentional to have the existing $SUBJECT. The commit 33f43725 updated the function text_to_array() such that it does not directly invoke

Re: [HACKERS] CTE inlining

On 1 May 2017 at 21:22, Andrew Dunstan wrote: > Having had years of telling users that CTEs are an optimization fence it > doesn't seem at all nice for us to turn around and change our mind about > that. I have relied on it in the past and I'm sure I'm very far

[HACKERS] check with serial

The other day I wanted to run "make check" but with the serial schedule. This wasn't as easy as it should have been. Although we now have installcheck-parallel we don't have check-serial. Should we have that? Alternatively, should we allow a SCHEDULE=foo argument for the "check" target which

Re: [HACKERS] PG 10 release notes

On 05/01/2017 05:40 AM, Robert Haas wrote: On Tue, Apr 25, 2017 at 9:56 PM, Bruce Momjian wrote: First, I don't think RFC references belong in the release notes, let alone RFC links. Why not? I think RFC references are a great thing to include in the release notes, and

Re: [HACKERS] CTE inlining

On 05/01/2017 09:05 AM, Tomas Vondra wrote: > On 05/01/2017 06:22 AM, Pavel Stehule wrote: >> >> >> 2017-05-01 1:21 GMT+02:00 Andres Freund > >: >> >> On 2017-04-30 07:19:21 +0200, Pavel Stehule wrote: >> > why we cannot to introduce GUC

Re: [HACKERS] Bug in prepared statement cache invalidation?

On Fri, Apr 28, 2017 at 3:01 AM, Konstantin Knizhnik wrote: > I find out that now Postgres correctly invalidates prepared plans which > directly depend on altered relation, but doesn't invalidate plans having > transitive (indirect) dependencies. I think the problem

Re: [HACKERS] snapbuild woes

On 05/01/2017 08:46 AM, Tom Lane wrote: > Noah Misch writes: >> On Fri, Apr 21, 2017 at 10:34:58PM -0700, Andres Freund wrote: >>> ... I was wondering about adding >>> a loop that simply runs for like 30s and then quits or such, but who >>> knows. >> If the probabilistic test

Re: [HACKERS] CTE inlining

On 05/01/2017 06:22 AM, Pavel Stehule wrote: 2017-05-01 1:21 GMT+02:00 Andres Freund >: On 2017-04-30 07:19:21 +0200, Pavel Stehule wrote: > why we cannot to introduce GUC option - enable_cteoptfence ? Doesn't really solve the issue,

Re: [HACKERS] vcregress support for single TAP tests

On 04/28/2017 08:54 AM, Andrew Dunstan wrote: > > On 04/26/2017 10:32 PM, Peter Eisentraut wrote: >> On 4/23/17 17:09, Andrew Dunstan wrote: >>> Here's a patch that will allow calling vcregress.pl to run a single TAP >>> test set. It would work like this: >>> >>> >>> vcregress.pl

Re: [HACKERS] snapbuild woes

Noah Misch writes: > On Fri, Apr 21, 2017 at 10:34:58PM -0700, Andres Freund wrote: >> ... I was wondering about adding >> a loop that simply runs for like 30s and then quits or such, but who >> knows. > If the probabilistic test catches the bug even 5% of the time in typical

Re: [HACKERS] PG 10 release notes

On Tue, Apr 25, 2017 at 9:56 PM, Bruce Momjian wrote: > First, I don't think RFC references belong in the release notes, let > alone RFC links. Why not? I think RFC references are a great thing to include in the release notes, and including links seems helpful, too. --

Re: [HACKERS] Declarative partitioning - another take

On Mon, May 1, 2017 at 12:18 AM, Amit Langote wrote: > Attached updated patch. Committed, except for this bit: +A statement-level trigger defined on partitioned tables is fired only +once for the table itself, not once for every table in the partitioning +

Re: [HACKERS] SCRAM in the PG 10 release notes

On Tue, Apr 25, 2017 at 10:16 PM, Bruce Momjian wrote: > Well, we could add "MD5 users are encouraged to switch to > SCRAM-SHA-256". Now whether we want to list this as something on the > SCRAM-SHA-256 description, or mention it as an incompatibility, or > under Migration. I

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 20 April 2017 at 07:29, Euler Taveira wrote: > 2017-04-19 1:32 GMT-03:00 Michael Paquier : >> >> I vote for "location" -> "lsn". I would expect complains about the >> current inconsistency at some point, and the function names have been >>

Re: [HACKERS] PG 10 release notes

On Tue, Apr 25, 2017 at 11:01 AM, Bruce Momjian wrote: >> Or the ability of logical decoding to follow timeline switches. > > I didn't think logical decoding was really more than a proof-of-concept > until now. /me searches for jaw on floor. It sounds like you don't understand

Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range

On Fri, Apr 28, 2017 at 10:02 PM, Dmitriy Sarafannikov wrote: > > What I'm thinking of is the regular indexscan that's done internally > by get_actual_variable_range, not whatever ends up getting chosen as > the plan for the user query. I had supposed that that would

Re: [HACKERS] some review comments on logical rep code

On Sat, Apr 29, 2017 at 12:33 AM, Noah Misch wrote: >> I think the patch that Fujii Masao has proposed has found general >> agreement. I would recommend that he commits it as he sees fit. > > This is not a conforming status update, because it does not specify a date for > your

Re: [HACKERS] RFC: ALTER SYSTEM [...] COMMENT

On Wed, Apr 26, 2017 at 10:33 PM, Joshua D. Drake wrote: > I propose: > > Add a column to pg_settings comment(text) > Change the grammar to allow: > > ALTER SYSTEM SET configuration_parameter { TO | = } { value | 'value' | > DEFAULT } COMMENT 'comment' > > Example: > >

Re: [HACKERS] snapbuild woes

On 01/05/17 10:03, Andres Freund wrote: > On 2017-05-01 03:54:49 +0200, Petr Jelinek wrote: >> I agree with adding running, I think that's good thing even for the per >> transaction tracking and snapshot exports - we could use the newly added >> field to get rid of the issue we have with 'snapshot

Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PG Hacking...

On Sun, Apr 30, 2017 at 10:47 AM, Andrew Borodin wrote: > Hi, Kang and everyone in this thread. > > I'm planning to present the online course "Hacking PostgreSQL: data > access methods in action and under the hood" on edX on June 1st. It's > not announced yet, links will be

Re: [HACKERS] snapbuild woes

On 2017-05-01 03:54:49 +0200, Petr Jelinek wrote: > I agree with adding running, I think that's good thing even for the per > transaction tracking and snapshot exports - we could use the newly added > field to get rid of the issue we have with 'snapshot too large' when > there were many aborted