Re: pgsql: Fix behavior of ~> (cube, int) operator

[Alexander Korotkov]

On Sun, Jan 21, 2018 at 11:20 PM, Tom Lane  wrote:

> Teodor Sigaev  writes:
> > Fix behavior of ~> (cube, int) operator
>
> This patch has caused Coverity to complain, correctly AFAICS, about
> dead code in cube_coord_llur in the back branches:
>
> 1628/* Inverse value if needed */
> 1629if (inverse)
> >>> CID 1463943:  Control flow issues  (DEADCODE)
> >>> Execution cannot reach this statement: "result = -result;".
> 1630result = -result;
> 1631
> 1632PG_RETURN_FLOAT8(result);
>
> Seems to be due to sloppy division of changes between f50c80dbb (which
> was not back-patched) and 563a053bd.  Please fix.
>

Thank you for catching this.  You diagnosis is right.
I propose to commit the attached patch to 10 and 9.6.

--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


cube_backpatch_fix.patch
Description: Binary data

Re: pgsql: Fix behavior of ~> (cube, int) operator

[Teodor Sigaev]

inverse variable becomes unused, will remove


Alexander Korotkov wrote:

Seems to be due to sloppy division of changes between f50c80dbb (which
was not back-patched) and 563a053bd.  Please fix.


Thank you for catching this.  You diagnosis is right.
I propose to commit the attached patch to 10 and 9.6.


--
Teodor Sigaev   E-mail: teo...@sigaev.ru
   WWW: http://www.sigaev.ru/

pgsql: Remove wrongly backpatched piece of code in cube.c

[Teodor Sigaev]

Remove wrongly backpatched piece of code in cube.c

Due to sloppy division of changes between f50c80dbb (which was not
back-patched) and 563a053bd, this piece of code was wrongly backpatched to
REL_10_STABLE and REL9_6_STABLE.  This code never causes real error because
its condition is never satisfied, but it's a dead code, which needs to be
removed.

Alexander Korotkov per gripe from Tom Lane

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/29ab1567e7ea4dccac75b60db3840db6f8859e40

Modified Files
--
contrib/cube/cube.c | 5 -
1 file changed, 5 deletions(-)

pgsql: Remove wrongly backpatched piece of code in cube.c

[Teodor Sigaev]

Remove wrongly backpatched piece of code in cube.c

Due to sloppy division of changes between f50c80dbb (which was not
back-patched) and 563a053bd, this piece of code was wrongly backpatched to
REL_10_STABLE and REL9_6_STABLE.  This code never causes real error because
its condition is never satisfied, but it's a dead code, which needs to be
removed.

Alexander Korotkov per gripe from Tom Lane

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/5b0fa06f65e959f73c145c8104cb3fa8505fca73

Modified Files
--
contrib/cube/cube.c | 5 -
1 file changed, 5 deletions(-)

Re: pgsql: Fix behavior of ~> (cube, int) operator

[Teodor Sigaev]

Pushed, thank you

Alexander Korotkov wrote:
On Sun, Jan 21, 2018 at 11:20 PM, Tom Lane > wrote:


Teodor Sigaev mailto:teo...@sigaev.ru>> writes:
> Fix behavior of ~> (cube, int) operator

This patch has caused Coverity to complain, correctly AFAICS, about
dead code in cube_coord_llur in the back branches:

1628            /* Inverse value if needed */
1629            if (inverse)
 >>>     CID 1463943:  Control flow issues  (DEADCODE)
 >>>     Execution cannot reach this statement: "result = -result;".
1630                    result = -result;
1631
1632            PG_RETURN_FLOAT8(result);

Seems to be due to sloppy division of changes between f50c80dbb (which
was not back-patched) and 563a053bd.  Please fix.


Thank you for catching this.  You diagnosis is right.
I propose to commit the attached patch to 10 and 9.6.

--
Alexander Korotkov
Postgres Professional:http://www.postgrespro.com 
The Russian Postgres Company


--
Teodor Sigaev   E-mail: teo...@sigaev.ru
   WWW: http://www.sigaev.ru/

pgsql: Fix comment on B-tree insertion fastpath condition.

[Heikki Linnakangas]

Fix comment on B-tree insertion fastpath condition.

The comment earlier in the function correctly states "and the insertion
key is strictly greater than the first key in this page". That is what
we check here, not "greater than or equal".

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/29d7ebf51ee33e1711fc9681f273f3de2da76ebf

Modified Files
--
src/backend/access/nbtree/nbtinsert.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

Re: pgsql: Fix comment on B-tree insertion fastpath condition.

[Pavan Deolasee]

On Tue, Apr 10, 2018 at 7:28 PM, Heikki Linnakangas <
heikki.linnakan...@iki.fi> wrote:

> Fix comment on B-tree insertion fastpath condition.
>
> The comment earlier in the function correctly states "and the insertion
> key is strictly greater than the first key in this page". That is what
> we check here, not "greater than or equal".
>
>
This was part of the follow-on patch that I'd sent (which needs a little
more adjustments based on Peter's feedback). But thanks for taking care of
it anyways.

Thanks,
Pavan

-- 
 Pavan Deolasee   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql: Fix pgxs.mk to not try to build generated headers in external bu

[Tom Lane]

Fix pgxs.mk to not try to build generated headers in external builds.

Per Julien Rouhaud and the buildfarm.  This is not quite Julien's
patch: there's no need to lobotomize this build rule when building
contrib modules in-tree, so set NO_GENERATED_HEADERS only if PGXS.

In passing, also set NO_TEMP_INSTALL in external builds.  This doesn't
seem to be fixing any live bug, because "make check" in an external
build just produces the expected error message without first trying to
make a temp install ... but it's far from obvious why it doesn't, so
this change seems like good future-proofing.

Julien Rouhaud and Tom Lane

Discussion: 
https://postgr.es/m/CAOBaU_YH=g68opbbmk8is3jnwhoxga8ckrsre1nx0obe1c7...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/1a40485af6e43be501500a88b1b9765cc0d69c0b

Modified Files
--
src/makefiles/pgxs.mk | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)

pgsql: Fix IndexOnlyScan counter for heap fetches in parallel mode

[Alvaro Herrera]

Fix IndexOnlyScan counter for heap fetches in parallel mode

The HeapFetches counter was using a simple value in IndexOnlyScanState,
which fails to propagate values from parallel workers; so the counts are
wrong when IndexOnlyScan runs in parallel.  Move it to Instrumentation,
like all the other counters.

While at it, change INSERT ON CONFLICT conflicting tuple counter to use
the new ntuples2 instead of nfiltered2, which is a blatant misuse.

Discussion: https://postgr.es/m/20180409215851.idwc75ct2bzi6tea@alvherre.pgsql

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/15a8f8caad14c1f85b23d97842d0c27b106cc10e

Modified Files
--
src/backend/commands/explain.c   | 10 +++---
src/backend/executor/instrument.c|  1 +
src/backend/executor/nodeIndexonlyscan.c |  3 +--
src/backend/executor/nodeModifyTable.c   |  4 ++--
src/include/executor/instrument.h|  1 +
src/include/nodes/execnodes.h|  7 +--
6 files changed, 13 insertions(+), 13 deletions(-)

Re: pgsql: Optimize btree insertions for common case of increasing values

[Pavan Deolasee]

On Tue, Apr 10, 2018 at 1:18 AM, Peter Geoghegan  wrote:

> On Thu, Apr 5, 2018 at 10:16 AM, Peter Geoghegan  wrote:
> > I think you can take that wording almost verbatim. Obviously it should
> > refer to the optimization by name, and blend into the surrounding text
> > in the README. I suggest putting a small section before "On-the-Fly
> > Deletion Of Index Tuples", but after the main discussion of deletion +
> > recycling. It's essentially an exception to the general rule, so that
> > placement makes sense to me.
>
> I also think that we should also say something about extent-based
> storage. This optimization relies on the assumption that reading some
> stale block cannot read a block from some other relation (which could
> perhaps be its own rightmost leaf page). If we ever wanted to share
> storage between small relations as extents, that would invalidate the
> optimization.
>
> This came up recently on the "PostgreSQL's handling of fsync() errors
> is unsafe and risks data loss at least on XFS" thread, and what I
> describe is in fact how other database systems manage storage, so this
> seems like a real practical consideration.
>
>
Hmm. I am a bit confused why we want to mention anything about something
we're not even considering seriously, let alone any patch or work in that
direction. If we at all change everything to use extent based storage,
there would be many other things that will break and require changes, no?

 Apart from that, other changes requested are included in the patch. This
also takes care of Heikki's observation regarding UNLOGGED tables on the
other thread.

Thanks,
Pavan

-- 
 Pavan Deolasee   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


0001-Post-commit-cleanup-for-B-Tree-optimization-work.patch
Description: Binary data

Re: pgsql: Optimize btree insertions for common case of increasing values

[Peter Geoghegan]

On Tue, Apr 10, 2018 at 12:07 PM, Pavan Deolasee
 wrote:
> Hmm. I am a bit confused why we want to mention anything about something
> we're not even considering seriously, let alone any patch or work in that
> direction. If we at all change everything to use extent based storage, there
> would be many other things that will break and require changes, no?

I guess you're right. It's implied by what you already say in the
nbtree README. No need to do more.

>  Apart from that, other changes requested are included in the patch. This
> also takes care of Heikki's observation regarding UNLOGGED tables on the
> other thread.

Cool.

Feedback on this version:

> +without a backend's cached page also being detected as invalidated, but
> +only when we happen to recycle a page that once again becomes the
> +rightmost leaf page.

I suggest wording this as "...but only when we happen to recycle a
block that once again gets recycled as the rightmost leaf page". (I'm
correcting my own wording here, I think.)

* No need to start a sentence with "So" here, IMV:

> +* Note the fact that whenever we fail to take the fastpath, we clear
> +* the cached block. So checking for a valid cached block at this 
> point
> +* is enough to decide whether we're in a fastpath or not.

* This should test "if (P_RIGHTMOST(lpageop) && P_ISLEAF(lpageop) &&
!P_ISROOT(lpageop))", because you don't want to use the optimization
for internal pages that happen to not be the root -- there is no leaf
check here:

> +   /*
> +* Cache the block information if we just inserted into the rightmost
> +* leaf page of the index and it's not the root page.  For very small
> +* index where root is also the leaf, there is no point trying for any
> +* optimisation.
> +*/
> +   if (P_RIGHTMOST(lpageop) && !P_ISROOT(lpageop))
> +   cachedBlock = BufferGetBlockNumber(buf);

* I don't think that you should have a #define inline with code like this:

> +#define BTREE_FASTPATH_MIN_LEVEL   2
> +   if (BlockNumberIsValid(cachedBlock) &&
> +   _bt_getrootheight(rel) >= BTREE_FASTPATH_MIN_LEVEL)
> +   RelationSetTargetBlock(rel, cachedBlock);

I suggest putting this in nbtree.h instead. You can put it just after
BTREE_NONLEAF_FILLFACTOR, with a comment, in a separate block/section.

Other than that, looks good to me.

Thanks
-- 
Peter Geoghegan

Re: pgsql: Optimize btree insertions for common case of increasing values

[Peter Geoghegan]

On Tue, Apr 10, 2018 at 12:30 PM, Peter Geoghegan  wrote:
>>  Apart from that, other changes requested are included in the patch. This
>> also takes care of Heikki's observation regarding UNLOGGED tables on the
>> other thread.
>
> Cool.

BTW, Heikki's commit didn't remove the "no split is in progress" part
of the top comment. I think that you can remove that now, but leave in
the separate P_INCOMPLETE_SPLIT() assertion that you've proposed.

-- 
Peter Geoghegan

pgsql: Put back parallel-safety guards in plpython and src/test/regress

[Tom Lane]

Put back parallel-safety guards in plpython and src/test/regress/.

I'd hoped that commit 3b8f6e75f was sufficient to ensure parallel safety
even when a build started in a subdirectory requires rebuilding of
generated headers.  This isn't so, because making submake-generated-headers
a prerequisite of "all" isn't enough to ensure it's completed before
starting on "all"'s other prerequisites.  The explicit dependencies we put
on the recursive make targets ensure safe ordering before we recurse into
child directories, but they don't protect targets to be made in the current
directory.  Hence, put back some ordering dependencies in directories that
we've traditionally expected to be starting points for "standalone" builds,
to wit src/pl/plpython and src/test/regress.  (The former needs this in
order to minimize the work involved in building for both python 2 and
python 3; the latter to support packagings that make the regression tests
available for out-of-build-tree execution.)  Adjust some other dependencies
so that these two cases work correctly even at high -j settings.

I'm not terribly happy with this partial solution, but I don't see a
way to do better without massive makefile restructuring, which we surely
aren't doing at this point in the development cycle.  In any case, it's
little if any worse than what we had in prior releases.

Discussion: https://postgr.es/m/1523353963.8169.26.ca...@gunduz.org

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/31f1f0bb4fd642643994d35c35ecb5b929711a99

Modified Files
--
src/Makefile.global.in   | 4 ++--
src/pl/plpython/Makefile | 3 +++
src/test/regress/GNUmakefile | 8 ++--
3 files changed, 11 insertions(+), 4 deletions(-)

pgsql: Adjustments to the btree fastpath optimization.

[Andrew Dunstan]

Adjustments to the btree fastpath optimization.

This optimization was introduced in commit 2b272734. The changes include
some additional comments and documentation, and also these more
substantive changes:
. ensure the optimization is only applied on the leaf node of a tree
whose root is on level 2 or more. It's of little value on small trees.
. Delay calling RelationSetTargetBlock() until after the critical
section of _bt_insertonpg
. ensure the optimization is also applied to unlogged tables.

Pavan Deolasee and Peter Geoghegan with some very light editing from me.

Discussion: 
https://postgr.es/m/caboikdo8jhrarnc60nzlktzyhxt+tk8z_v97+ny499yqdya...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/074251db6740a9abfbd922d13d39b27c4f338a20

Modified Files
--
src/backend/access/nbtree/README  | 19 +++
src/backend/access/nbtree/nbtinsert.c | 63 +--
2 files changed, 71 insertions(+), 11 deletions(-)

Re: pgsql: Optimize btree insertions for common case of increasing values

[Andrew Dunstan]

On 04/10/2018 03:30 PM, Peter Geoghegan wrote:
> On Tue, Apr 10, 2018 at 12:07 PM, Pavan Deolasee
>  wrote:
>> Hmm. I am a bit confused why we want to mention anything about something
>> we're not even considering seriously, let alone any patch or work in that
>> direction. If we at all change everything to use extent based storage, there
>> would be many other things that will break and require changes, no?
> I guess you're right. It's implied by what you already say in the
> nbtree README. No need to do more.
>
>>  Apart from that, other changes requested are included in the patch. This
>> also takes care of Heikki's observation regarding UNLOGGED tables on the
>> other thread.
> Cool.
>
> Feedback on this version:
>
>> +without a backend's cached page also being detected as invalidated, but
>> +only when we happen to recycle a page that once again becomes the
>> +rightmost leaf page.
> I suggest wording this as "...but only when we happen to recycle a
> block that once again gets recycled as the rightmost leaf page". (I'm
> correcting my own wording here, I think.)
>
> * No need to start a sentence with "So" here, IMV:
>
>> +* Note the fact that whenever we fail to take the fastpath, we clear
>> +* the cached block. So checking for a valid cached block at this 
>> point
>> +* is enough to decide whether we're in a fastpath or not.
> * This should test "if (P_RIGHTMOST(lpageop) && P_ISLEAF(lpageop) &&
> !P_ISROOT(lpageop))", because you don't want to use the optimization
> for internal pages that happen to not be the root -- there is no leaf
> check here:
>
>> +   /*
>> +* Cache the block information if we just inserted into the rightmost
>> +* leaf page of the index and it's not the root page.  For very small
>> +* index where root is also the leaf, there is no point trying for 
>> any
>> +* optimisation.
>> +*/
>> +   if (P_RIGHTMOST(lpageop) && !P_ISROOT(lpageop))
>> +   cachedBlock = BufferGetBlockNumber(buf);
> * I don't think that you should have a #define inline with code like this:
>
>> +#define BTREE_FASTPATH_MIN_LEVEL   2
>> +   if (BlockNumberIsValid(cachedBlock) &&
>> +   _bt_getrootheight(rel) >= BTREE_FASTPATH_MIN_LEVEL)
>> +   RelationSetTargetBlock(rel, cachedBlock);
> I suggest putting this in nbtree.h instead. You can put it just after
> BTREE_NONLEAF_FILLFACTOR, with a comment, in a separate block/section.
>
> Other than that, looks good to me.
>


Committed with light editing. I didn't put the #define in the .h file -
it's only used here and that seemed like unnecessary clutter. I moved it
to the top of the file. I also standardized the spelling of "optimization".

cheers

andrew

Re: pgsql: Optimize btree insertions for common case of increasing values

[Peter Geoghegan]

On Tue, Apr 10, 2018 at 3:27 PM, Andrew Dunstan  wrote:
> Committed with light editing. I didn't put the #define in the .h file -
> it's only used here and that seemed like unnecessary clutter. I moved it
> to the top of the file. I also standardized the spelling of "optimization".

The comments still say "Check if the page...no split is in progress".
Despite the fact that that's just an assertion now.

-- 
Peter Geoghegan

pgsql: Fix incorrect close() call in dsm_impl_mmap().

[Tom Lane]

Fix incorrect close() call in dsm_impl_mmap().

One improbable error-exit path in this function used close() where
it should have used CloseTransientFile().  This is unlikely to be
hit in the field, and I think the consequences wouldn't be awful
(just an elog(LOG) bleat later).  But a bug is a bug, so back-patch
to 9.4 where this code came in.

Pan Bian

Discussion: 
https://postgr.es/m/152056616579.4966.583293218357089...@wrigleys.postgresql.org

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/231bcd0803eb91c526d4e7522c993fa5ed71bd45

Modified Files
--
src/backend/storage/ipc/dsm_impl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Fix incorrect close() call in dsm_impl_mmap().

[Tom Lane]

Fix incorrect close() call in dsm_impl_mmap().

One improbable error-exit path in this function used close() where
it should have used CloseTransientFile().  This is unlikely to be
hit in the field, and I think the consequences wouldn't be awful
(just an elog(LOG) bleat later).  But a bug is a bug, so back-patch
to 9.4 where this code came in.

Pan Bian

Discussion: 
https://postgr.es/m/152056616579.4966.583293218357089...@wrigleys.postgresql.org

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/02ba72ec1cf541d735c993f11342784969f65b45

Modified Files
--
src/backend/storage/ipc/dsm_impl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Fix incorrect close() call in dsm_impl_mmap().

[Tom Lane]

Fix incorrect close() call in dsm_impl_mmap().

One improbable error-exit path in this function used close() where
it should have used CloseTransientFile().  This is unlikely to be
hit in the field, and I think the consequences wouldn't be awful
(just an elog(LOG) bleat later).  But a bug is a bug, so back-patch
to 9.4 where this code came in.

Pan Bian

Discussion: 
https://postgr.es/m/152056616579.4966.583293218357089...@wrigleys.postgresql.org

Branch
--
REL9_5_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/2224d1ce144789bf108382f4fdec9f9e9dcf385a

Modified Files
--
src/backend/storage/ipc/dsm_impl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Fix incorrect close() call in dsm_impl_mmap().

[Tom Lane]

Fix incorrect close() call in dsm_impl_mmap().

One improbable error-exit path in this function used close() where
it should have used CloseTransientFile().  This is unlikely to be
hit in the field, and I think the consequences wouldn't be awful
(just an elog(LOG) bleat later).  But a bug is a bug, so back-patch
to 9.4 where this code came in.

Pan Bian

Discussion: 
https://postgr.es/m/152056616579.4966.583293218357089...@wrigleys.postgresql.org

Branch
--
REL9_4_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/f530af8fc931b4063f1a9f4239908c7110666848

Modified Files
--
src/backend/storage/ipc/dsm_impl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Fix incorrect close() call in dsm_impl_mmap().

[Tom Lane]

Fix incorrect close() call in dsm_impl_mmap().

One improbable error-exit path in this function used close() where
it should have used CloseTransientFile().  This is unlikely to be
hit in the field, and I think the consequences wouldn't be awful
(just an elog(LOG) bleat later).  But a bug is a bug, so back-patch
to 9.4 where this code came in.

Pan Bian

Discussion: 
https://postgr.es/m/152056616579.4966.583293218357089...@wrigleys.postgresql.org

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/494f3cb5bbdae3d75b0100559a8a05020e8338ff

Modified Files
--
src/backend/storage/ipc/dsm_impl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: minor comment fixes in nbtinsert.c

[Andrew Dunstan]

minor comment fixes in nbtinsert.c

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/8716b264ed845370e33943da93caf424dc3723b7

Modified Files
--
src/backend/access/nbtree/nbtinsert.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)

Re: pgsql: Optimize btree insertions for common case of increasing values

[Andrew Dunstan]

On 04/10/2018 06:33 PM, Peter Geoghegan wrote:
> On Tue, Apr 10, 2018 at 3:27 PM, Andrew Dunstan  wrote:
>> Committed with light editing. I didn't put the #define in the .h file -
>> it's only used here and that seemed like unnecessary clutter. I moved it
>> to the top of the file. I also standardized the spelling of "optimization".
> The comments still say "Check if the page...no split is in progress".
> Despite the fact that that's just an assertion now.
>

Fixed.

cheers

andrew

-- 
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: pgsql: Optimize btree insertions for common case of increasing values

[Peter Geoghegan]

On Tue, Apr 10, 2018 at 3:37 PM, Andrew Dunstan
 wrote:
>> The comments still say "Check if the page...no split is in progress".
>> Despite the fact that that's just an assertion now.
>>
>
> Fixed.

Thanks.

-- 
Peter Geoghegan

Re: pgsql: Support partition pruning at execution time

[David Rowley]

On 10 April 2018 at 08:55, Tom Lane  wrote:
> Alvaro Herrera  writes:
>> David Rowley wrote:
>>> Okay, I've written and attached a fix for this.  I'm not 100% certain
>>> that this is the cause of the problem on pademelon, but the code does
>>> look wrong, so needs to be fixed. Hopefully, it'll make pademelon
>>> happy, if not I'll think a bit harder about what might be causing that
>>> instability.
>
>> Pushed it just now.  Let's see what happens with pademelon now.
>
> I've had pademelon's host running a "make installcheck" loop all day
> trying to reproduce the problem.  I haven't gotten a bite yet (although
> at 15+ minutes per cycle, this isn't a huge number of tests).  I think
> we were remarkably (un)lucky to see the problem so quickly after the
> initial commit, and I'm afraid pademelon isn't going to help us prove
> much about whether this was the same issue.
>
> This does remind me quite a bit though of the ongoing saga with the
> postgres_fdw test instability.  Given the frequency with which that's
> failing in the buildfarm, you would not think it's impossible to
> reproduce outside the buildfarm, and yet I'm here to tell you that
> it's pretty damn hard.  I haven't succeeded yet, and that's not for
> lack of trying.  Could there be something about the buildfarm
> environment that makes these sorts of things more likely?

coypu just demonstrated that this was not the cause of the problem [1]

I'll study the code a bit more and see if I can think why this might
be happening.

[1] 
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=coypu&dt=2018-04-11%2004%3A17%3A38&stg=install-check-C

-- 
 David Rowley   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services