Re: [HACKERS] Race conditions with WAL sender PID lookups

On Sat, Jul 1, 2017 at 7:20 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> Considering how crazy the conditions to make the information fetched >> by users inconsistent are met, I agree with that. > > Pushed. Thanks Álvaro for pushing the patch. I had a second

Re: [HACKERS] Multi column range partition table

On 2017/07/03 2:15, Dean Rasheed wrote: > On 30 June 2017 at 10:04, Ashutosh Bapat > wrote: >> On Fri, Jun 30, 2017 at 1:36 PM, Amit Langote >> wrote: >>> >>> Alright, I spent some time implementing a patch to allow specifying >>>

Re: [HACKERS] Broken hint bits (freeze)

On Thu, Jun 29, 2017 at 6:57 AM, Bruce Momjian wrote: > On Sat, Jun 24, 2017 at 09:24:21AM +0530, Amit Kapila wrote: >> > I was not clear. I was not saying there can be only one extra WAL file. >> > I am saying the "Latest checkpoint location" should be one WAL file >> >

[HACKERS] hash index on unlogged tables doesn't behave as expected

While discussing the behavior of hash indexes with Bruce in the nearby thread [1], it has been noticed that hash index on unlogged tables doesn't behave as expected. Prior to 10, it has the different set of problems (mainly because hash indexes are not WAL-logged) which were discussed on that

Re: [HACKERS] "SELECT *" vs hidden columns and logical column order

On Sat, Jul 1, 2017 at 6:09 AM, Peter Eisentraut wrote: > On 6/28/17 23:52, Thomas Munro wrote: >> 2. SQL:2011 temporal tables track system time and/or valid time with >> columns that users create and then declare to be temporal control >> columns. I don't

Re: [BUGS] [HACKERS] Segmentation fault in libpq

On 3 July 2017 at 03:12, Andres Freund wrote: > Hi, > > On 2017-07-02 20:58:52 +0200, Michal Novotný wrote: >> thank you all for your advice. I've been investigating this a little more >> and finally it turned out it's not a bug in libpq although I got confused >> by going

Re: [HACKERS] Multi column range partition table

Hi Dean, Thanks a lot for the review. On 2017/07/03 1:59, Dean Rasheed wrote: > On 30 June 2017 at 09:06, Amit Langote wrote: >> When testing the patch, I realized that the current code in >> check_new_partition_bound() that checks for range partition overlap had

Re: [HACKERS] Get stuck when dropping a subscription during synchronizing table

On Wed, Jun 28, 2017 at 2:13 PM, Masahiko Sawada wrote: > On Wed, Jun 28, 2017 at 1:47 AM, Petr Jelinek > wrote: >> >> On 27/06/17 10:51, Masahiko Sawada wrote: >>> On Mon, Jun 26, 2017 at 12:12 PM, Masahiko Sawada >>>

Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl

Craig Ringer writes: > That's my bad. > (Insert dark muttering about Perl here). Yeah, pretty much the only good thing about Perl is it's ubiquitous. But you could say the same of C. Or SQL. For a profession that's under 70 years old, we sure spend a lot of time dealing

Re: [HACKERS] PostgresNode::poll_query_until hacking

Michael Paquier writes: > If you would like to get some feedback from me, waiting until Monday > morning my time (Sunday evening yours) before pushing patches would be > better. If you have ideas for improvement, it's always possible to amend the code later. I've been

Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl

On 3 July 2017 at 05:10, Tom Lane wrote: > I wrote: >> Any ideas what's wrong there? > > Hah: the answer is that query_hash's split() call is broken. > "man perlfunc" quoth > >split Splits the string EXPR into a list of strings and returns that >list.

Re: [HACKERS] Typo in comment in xlog.c: ReadRecord

On 2017/07/01 3:49, Peter Eisentraut wrote: > On 6/27/17 20:54, Amit Langote wrote: >> Attached fixes $SUBJECT. >> >> s/fetch_ckpt/fetching_ckpt/g > > committed Thanks. Regards, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Fix a typo in aclchk.c

On Sat, Jul 1, 2017 at 4:55 AM, Peter Eisentraut wrote: > On 6/30/17 03:58, Masahiko Sawada wrote: >> Attached patch for $subject. >> >> s/entires/entries/ > > fixed > Thanks. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open

Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl

Michael Paquier writes: > On Mon, Jul 3, 2017 at 7:02 AM, Tom Lane wrote: >> Anyone have a different view of what to fix here? > No, this sounds like a good plan. What do you think about the attached? Oh, that's a good way. I just finished

Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl

(catching up test threads) On Mon, Jul 3, 2017 at 7:02 AM, Tom Lane wrote: > I'm now inclined to think that the correct fix is to ensure that we > run synchronous rep in both directions, rather than to insert delays > to substitute for that. Just setting

Re: [HACKERS] PostgresNode::poll_query_until hacking

On Sun, Jul 2, 2017 at 4:53 AM, Tom Lane wrote: > The attached proposed patch changes the TAP test infrastructure's > poll_query_until function in two ways: > > 1. An optional argument is added to allow specifying the query result > value we're waiting for, overriding the

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

On Sat, Jul 1, 2017 at 4:47 AM, Peter Eisentraut wrote: > On 5/1/17 12:19, Peter Eisentraut wrote: >> However: Failure to complete promotion within the waiting time does not >> lead to an error exit, so you will not get a failure if the promotion >> does not

[HACKERS] More race conditions in logical replication

I noticed a recent failure that looked suspiciously like a race condition: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet=2017-07-02%2018%3A02%3A07 The critical bit in the log file is error running SQL: 'psql::1: ERROR: could not drop the replication slot "tap_sub" on

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On Thu, Jun 29, 2017 at 7:29 PM, Satyanarayana Narlapuram wrote: > -Original Message- The formatting of this message differs from the style normally used on this mailing list, and is hard to read. > 2. If the client version is anything other than

Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl

I wrote: > Anyway, having vented about that ... it's not very clear to me whether the > test script is at fault for not being careful to let the slave catch up to > the master before we promote it (and then deem the master to be usable as > a slave without rebuilding it first), or whether we

Re: [HACKERS] Using postgres planner as standalone component

On 01/07/17 22:48, Ricky Stevens wrote: Hi, For one of my personal projects I am interested in using the PostgreSQL planner as a standalone library. However, I would like to run this as an embedded library instead of actually creating anything on disk. I've realized that postgres has

Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl

I wrote: > Any ideas what's wrong there? Hah: the answer is that query_hash's split() call is broken. "man perlfunc" quoth split Splits the string EXPR into a list of strings and returns that list. By default, empty leading fields are preserved, and empty

Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl

I wrote: > The reporting critters are all on the slow side, so I suspected > a timing problem, especially since it only started to show up > after changing pg_ctl's timing behavior. I can't reproduce it > locally on unmodified sources, but I could after putting my thumb > on the scales like this:

Re: [BUGS] [HACKERS] Segmentation fault in libpq

Hi all, thank you all for your advice. I've been investigating this a little more and finally it turned out it's not a bug in libpq although I got confused by going deep as several libpq functions. The bug was really on our side after trying to use connection pointer after calling PQfinish(). The

Re: [BUGS] [HACKERS] Segmentation fault in libpq

Hi, On 2017-07-02 20:58:52 +0200, Michal Novotný wrote: > thank you all for your advice. I've been investigating this a little more > and finally it turned out it's not a bug in libpq although I got confused > by going deep as several libpq functions. The bug was really on our side > after trying

Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl

Alvaro Herrera writes: > Tom Lane wrote: >> * Some effort should be put into emitting text to the log showing >> what's going on, eg print("Now london is master."); as appropriate. > Check. Not "print" though; I think using note(" .. ") (from Test::More) > is more

[HACKERS] WIP patch for avoiding duplicate initdb runs during "make check"

Yesterday I spent a bit of time on an idea that we've talked about before, which is to not run initdb over and over again in contexts like "make check-world", or even just during "make check" in contrib or in the recovery or subscription tests. The idea would be to do it once and then copy the

Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl

Tom Lane wrote: > I'd kind of like to fix it now, so I can reason in a less confused way > about the actual problem. OK, no objections here. > Last night I didn't have a clear idea of how > to make it better, but what I'm thinking this morning is: > > * Naming the underlying server objects

Re: [HACKERS] Multi column range partition table

On 30 June 2017 at 10:04, Ashutosh Bapat wrote: > On Fri, Jun 30, 2017 at 1:36 PM, Amit Langote > wrote: >> >> Alright, I spent some time implementing a patch to allow specifying >> -infinity and +infinity in arbitrary ways. Of

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Tue, Jun 27, 2017 at 11:41 AM, Mithun Cy wrote: > On Fri, Jun 23, 2017 at 5:45 AM, Thom Brown wrote: >> >> Also, I find it a bit messy that launch_autoprewarm_dump() doesn't >> detect an autoprewarm process already running. I'd want this to >>

Re: [HACKERS] Multi column range partition table

On 30 June 2017 at 09:06, Amit Langote wrote: > When testing the patch, I realized that the current code in > check_new_partition_bound() that checks for range partition overlap had a > latent bug that resulted in false positives for the new cases that the new >

Re: [HACKERS] Using postgres planner as standalone component

Ricky Stevens writes: > For one of my personal projects I am interested in using the PostgreSQL > planner as a standalone library. However, I would like to run this as an > embedded library instead of actually creating anything on disk. I'm not really clear on what value

[HACKERS] Using postgres planner as standalone component

Hi, For one of my personal projects I am interested in using the PostgreSQL planner as a standalone library. However, I would like to run this as an embedded library instead of actually creating anything on disk. I've realized that postgres has several pg_operator, pg_class etc. tables which it

Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl

Alvaro Herrera writes: > Tom Lane wrote: >> Part of the reason I'm confused is that the programming technique >> being used in 009_twophase.pl, namely doing >> ($node_master, $node_slave) = ($node_slave, $node_master); >> and then working with the reversed variable

Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl

Tom Lane wrote: > Part of the reason I'm confused is that the programming technique > being used in 009_twophase.pl, namely doing > > ($node_master, $node_slave) = ($node_slave, $node_master); > > and then working with the reversed variable names, is ENTIRELY TOO CUTE > FOR ITS OWN GOOD.

Re: [HACKERS] UPDATE of partition key

On Fri, Jun 30, 2017 at 4:20 PM, Robert Haas wrote: > I don't think the approach of building a hash table to figure out > which result rels have already been created is a good one. That too > feels like something that the planner should be figuring out and the > executor

Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server

On Sat, Jul 1, 2017 at 3:59 AM, Stephen Frost wrote: > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: >> On 6/30/17 04:08, Masahiko Sawada wrote: >> >> I'm not sure. I think this can be considered a bug in the implementation >> >> for >> >> 10, and as such is