Avoid uninterruptable waits in SharedQ

Instead we wait with a small timeout (10s) and retry things (which we were
doing anyways). This also allows us to process any pending interrupts.

Handle regression failures post merge with 10.6

Merge tag 'REL_10_6' into XL_10_STABLE

Initialise PGXCNodeIdentifier as part of multi-executor setup

We used to do this while creating a portal. It's not clear why that place was
chosen by the original author, but it seems more logical to do so while setting
up multi-node execution environment. This also solves the problem of a parallel
worker not seeing the correct state, as reported by Virendra Kumar.

Use own transactions while running ANALYZE

Commit c89ea7fe8d1686c78a31781449342ca2e056caea disabled running ANALYZE on
remote coordinators when done inside a transaction block. But per report from
Virendra Kumar, this has also affected ANALYZE outside transaction blocks
because the existing code was using own transactions only either for autovacuum
processes or when more than one tables are analyzed at the same time.

Work-around this by always using own transaction except when ANALYZE is
triggered by REFRESH MATERIALIZED VIEW, which doesn't like closing the current
transaction.

Change a elog(LOG) to elog(DEBUG2)

It was accidentally left at LOG level. Per report from Krzysztof Nienartowicz

Stamp 10.6.

Last-minute updates for release notes.

I removed the item about the pg_stat_statements change from
release-11.sgml, as part of a sweep to delete items already committed
in 11.0; but actually we'd best keep it to ensure that people who've
pg_upgraded their databases will take the requisite action.  Also make
said action more visible by making it into its own para.  Noted by
Jonathan Katz.

Fix copy-paste error in errhint() introduced in 691d79a07933.

Reported-By: Petr Jelinek
Discussion: https://postgr.es/m/c95a620b-34f0-7930-aeb5-f7ab804f26cb@2ndquadrant.com
Backpatch: 9.4-, like the previous commit

Last-minute updates for release notes.

Security: CVE-2018-16850

Translation updates

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 4aac9391521d21fdecc378db4750a59795350b33

Block creation of partitions with open references to its parent

When a partition is created as part of a trigger processing, it is
possible that the partition which just gets created changes the
properties of the table the executor of the ongoing command relies on,
causing a subsequent crash.  This has been found possible when for
example using a BEFORE INSERT which creates a new partition for a
partitioned table being inserted to.

Any attempt to do so is blocked when working on a partition, with
regression tests added for both CREATE TABLE PARTITION OF and ALTER
TABLE ATTACH PARTITION.

Reported-by: Dmitry Shalashov
Author: Amit Langote
Reviewed-by: Michael Paquier, Tom Lane
Discussion: https://postgr.es/m/15437-3fe01ee66bd1bae1@postgresql.org
Backpatch-through: 10

Ignore partitioned tables when processing ON COMMIT DELETE ROWS

Those tables have no physical storage, making this option unusable with
partition trees as at commit time an actual truncation was attempted.
There are still issues with the way ON COMMIT actions are done when
mixing several action types, however this impacts as well inheritance
trees, so this issue will be dealt with later.

Reported-by: Rajkumar Raghuwanshi
Author: Amit Langote
Reviewed-by: Michael Paquier, Tom Lane
Discussion: https://postgr.es/m/CAKcux6mhgcjSiB_egqEAEFgX462QZtncU8QCAJ2HZwM-wWGVew@mail.gmail.com

Release notes for 11.1, 10.6, 9.6.11, 9.5.15, 9.4.20, 9.3.25.

Make ts_locale.c's character-type functions cope with UTF-16.

On Windows, in UTF8 database encoding, what char2wchar() produces is
UTF16 not UTF32, ie, characters above U+FFFF will be represented by
surrogate pairs.  t_isdigit() and siblings did not account for this
and failed to provide a large enough result buffer.  That in turn
led to bogus "invalid multibyte character for locale" errors, because
contrary to what you might think from char2wchar()'s documentation,
its Windows code path doesn't cope sanely with buffer overflow.

The solution for t_isdigit() and siblings is pretty clear: provide
a 3-wchar_t result buffer not 2.

char2wchar() also needs some work to provide more consistent, and more
accurately documented, buffer overrun behavior.  But that's a bigger job
and it doesn't actually have any immediate payoff, so leave it for later.

Per bug #15476 from Kenji Uno, who deserves credit for identifying the
cause of the problem.  Back-patch to all active branches.

Discussion: https://postgr.es/m/15476-4314f480acf0f114@postgresql.org

Remove extra word from create sub docs

Improve the documentation in the CREATE SUBSCRIPTION command a bit by
removing an extraneous word and spelling out 'information'.

Yet further rethinking of build changes for macOS Mojave.

The solution arrived at in commit e74dd00f5 presumes that the compiler
has a suitable default -isysroot setting ... but further experience
shows that in many combinations of macOS version, XCode version, Xcode
command line tools version, and phase of the moon, Apple's compiler
will *not* supply a default -isysroot value.

We could potentially go back to the approach used in commit 68fc227dd,
but I don't have a lot of faith in the reliability or life expectancy of
that either.  Let's just revert to the approach already shipped in 11.0,
namely specifying an -isysroot switch globally.  As a partial response to
the concerns raised by Jakob Egger, adjust the contents of Makefile.global
to look like

CPPFLAGS = -isysroot $(PG_SYSROOT) ...
PG_SYSROOT = /path/to/sysroot

This allows overriding the sysroot path at build time in a relatively
painless way.

Add documentation to installation.sgml about how to use the PG_SYSROOT
option.  I also took the opportunity to document how to work around
macOS's "System Integrity Protection" feature.

As before, back-patch to all supported versions.

Discussion: https://postgr.es/m/20840.1537850987@sss.pgh.pa.us

docs:  adjust simpler language for NULL return from ANY/ALL

Adjustment to commit 8610c973ddf1cbf0befc1369d2cf0d56c0efcd0a.

Reported-by: Tom Lane
Discussion: https://postgr.es/m/17406.1541168421@sss.pgh.pa.us

Backpatch-through: 9.3

GUC:  adjust effective_cache_size docs and SQL description

Clarify that effective_cache_size is both kernel buffers and shared
buffers.

Reported-by: [email protected]
Discussion: https://postgr.es/m/153685164808.22334.15432535018443165207@wrigleys.postgresql.org

Backpatch-through: 9.3

Fix some spelling errors in the documentation

Author: Daniel Gustafsson <[email protected]>

doc:  use simpler language for NULL return from ANY/ALL

Previously the combination of "does not return" and "any row" caused
ambiguity.

Reported-by: KES <[email protected]>
Discussion: https://postgr.es/m/153701242703.22334.1476830122267077397@wrigleys.postgresql.org

Reviewed-by: David G. Johnston
Backpatch-through: 9.3

Fix error message typo introduced 691d79a07933.

Reported-By: Michael Paquier
Discussion: https://postgr.es/m/20181101003405[email protected]
Backpatch: 9.4-, like the previous commit

Disallow starting server with insufficient wal_level for existing slot.

Previously it was possible to create a slot, change wal_level, and
restart, even if the new wal_level was insufficient for the
slot. That's a problem for both logical and physical slots, because
the necessary WAL records are not generated.

This removes a few tests in newer versions that, somewhat
inexplicably, whether restarting with a too low wal_level worked (a
buggy behaviour!).

Reported-By: Joshua D. Drake
Author: Andres Freund
Discussion: https://postgr.es/m/20181029191304[email protected]
Backpatch: 9.4-, where replication slots where introduced

Fix memory leak in repeated SPGIST index scans.

spgendscan neglected to pfree all the memory allocated by spgbeginscan.
It's possible to get away with that in most normal queries, since the
memory is allocated in the executor's per-query context which is about
to get deleted anyway; but it causes severe memory leakage during
creation or filling of large exclusion-constraint indexes.

Also, document that amendscan is supposed to free what ambeginscan
allocates.  The docs' lack of clarity on that point probably caused this
bug to begin with.  (There is discussion of changing that API spec going
forward, but I don't think it'd be appropriate for the back branches.)

Per report from Bruno Wolff.  It's been like this since the beginning,
so back-patch to all active branches.

In HEAD, also fix an independent leak caused by commit 2a6368343
(allocating memory during spgrescan instead of spgbeginscan, which
might be all right if it got cleaned up, but it didn't).  And do a bit
of code beautification on that commit, too.

Discussion: https://postgr.es/m/20181024012314[email protected]

Sync our copy of the timezone library with IANA release tzcode2018g.

This patch absorbs an upstream fix to "zic" for a recently-introduced
bug that made it output data that some 32-bit clients couldn't read.
Given the current source data, the bug only manifests in zones with
leap seconds, which we don't generate, so that there's no actual
change in our installed timezone data files from this.  Still, in
case somebody uses our copy of "zic" to do something else, it seems
best to apply the fix promptly.

Also, update the README's notes about converting upstream code to
our conventions.

Update time zone data files to tzdata release 2018g.

DST law changes in Morocco (with, effectively, zero notice).
Historical corrections for Hawaii.

Add a new option to vacuumdb command

We now support --coordinator-only option in vacuumdb command to simply update
the coordinator side statistics without forcing a fresh analyze on the
datanodes. The pgxc_ctl uses this new facility to update statistics on a newly
added coordinator.

Per complaint by Virendra Kumar

Fix missing whitespace in pg_dump ref page

Author: Daniel Gustafsson <[email protected]>

pg_restore: Augment documentation for -N option

This was forgotten when the option was added.

Author: Michael Banck <[email protected]>

Fix perl searchpath for modern perl for MSVC tools

Modern versions of perl no longer include the current directory in the
perl searchpath, as it's insecure. Instead of adding the current
directory, we get around the problem by adding the directory where the
script lives.

Problem noted by Victor Wagner.

Solution adapted from buildfarm client code.

Backpatch to all live versions.

Force READ WRITE transaction while running pg_rewind

Since direct connections to a datanode by default use read-only transactions,
we need to explicitly set transaction as read write so that temporary tables
can be created and written to.

Report and patch by Virendra Kumar.

Provide enough space for knownXids array

Commit be7777d2a9d8d70c931e80868f4f7e373f3f98f8 rearranged things so that the
intial XID value is set appropriately in the GTM control file. But that seems
to have caused problem with a standby setup and the array to hold knownXids is
no longer enough. Hence make some adjustments there.

This was stopping a standby from starting up correctly as observed during the
tests.

Allow RECURSIVE queries on function scans

Put proper date against GA release

Fix a typo

Stamp XL 10r1 GA

List wait events in alphabetical order in documentation

Keeping all those entries in order helps the user looking at the
documentation in finding them.

Author: Michael Paquier, Kuntal Ghosh
Discussion: https://postgr.es/m/20181024002539[email protected]

Update release notes from XL 10r1 GA release

Add two more parameters to pgxc_ctl.conf

pgxc_ctl sets up postgresql.conf and recovery.conf while adding and removing a
coordinator/datanode standby. This interfers with user defined settings if the
user has chosen different mechanism for backup/recovery, such as barman. So
this band-aid fix avoids overwriting the user defined values while
adding/removing standbys. We assume that if these parameters are set to 'y'
(the default is 'n' which means the default old behaviour), then the user would
manually setup things correctly.

Use wal_level=replica as hot_standby is deprecated

Catch and report GTM errors correctly

If the connection with the GTM is dropped, we should ensure that the caller
gets to see the error. This fixes some of the issues noticed during GTM
stop/start tests.

Fix some grammar errors in bloom.sgml

Discussion:  https://postgr.es/m/CAEepm%3D3sijpGr8tXdyz-7EJJZfhQHABPKEQ29gpnb7-XSy%2B%3D5A%40mail.gmail.com
Reported-by: Thomas Munro
Backpatch-through: 9.6

Lower privilege level of programs calling regression_main

On Windows this mean that the regression tests can now safely and
successfully run as Administrator, which is useful in situations like
Appveyor. Elsewhere it's a no-op.

Backpatch to 9.5 - this is harder in earlier branches and not worth the
trouble.

Discussion: https://postgr.es/m/650b0c29-9578-8571-b1d2-550d7f89f307@2ndQuadrant.com

Client-side fixes for delayed NOTIFY receipt.

PQnotifies() is defined to just process already-read data, not try to read
any more from the socket.  (This is a debatable decision, perhaps, but I'm
hesitant to change longstanding library behavior.)  The documentation has
long recommended calling PQconsumeInput() before PQnotifies() to ensure
that any already-arrived message would get absorbed and processed.
However, psql did not get that memo, which explains why it's not very
reliable about reporting notifications promptly.

Also, most (not quite all) callers called PQconsumeInput() just once before
a PQnotifies() loop.  Taking this recommendation seriously implies that we
should do PQconsumeInput() before each call.  This is more important now
that we have "payload" strings in notification messages than it was before;
that increases the probability of having more than one packet's worth
of notify messages.  Hence, adjust code as well as documentation examples
to do it like that.

Back-patch to 9.5 to match related server fixes.  In principle we could
probably go back further with these changes, but given lack of field
complaints I doubt it's worthwhile.

Discussion: https://postgr.es/m/CAOYf6ec-TmRYjKBXLLaGaB-jrd=mjG1Hzn1a1wufUAR39PQYhw@mail.gmail.com

Server-side fix for delayed NOTIFY and SIGTERM processing.

Commit 4f85fde8e introduced some code that was meant to ensure that we'd
process cancel, die, sinval catchup, and notify interrupts while waiting
for client input.  But there was a flaw: it supposed that the process
latch would be set upon arrival at secure_read() if any such interrupt
was pending.  In reality, we might well have cleared the process latch
at some earlier point while those flags remained set -- particularly
notifyInterruptPending, which can't be handled as long as we're within
a transaction.

To fix the NOTIFY case, also attempt to process signals (except
ProcDiePending) before trying to read.

Also, if we see that ProcDiePending is set before we read, forcibly set the
process latch to ensure that we will handle that signal promptly if no data
is available.  I also made it set the process latch on the way out, in case
there is similar logic elsewhere.  (It remains true that we won't service
ProcDiePending here unless we need to wait for input.)

The code for handling ProcDiePending during a write needs those changes,
too.

Also be a little more careful about when to reset whereToSendOutput,
and improve related comments.

Back-patch to 9.5 where this code was added.  I'm not entirely convinced
that older branches don't have similar issues, but the complaint at hand
is just about the >= 9.5 code.

Jeff Janes and Tom Lane

Discussion: https://postgr.es/m/CAOYf6ec-TmRYjKBXLLaGaB-jrd=mjG1Hzn1a1wufUAR39PQYhw@mail.gmail.com

Sync our copy of the timezone library with IANA release tzcode2018f.

About half of this is purely cosmetic changes to reduce the diff between
our code and theirs, like inserting "const" markers where they have them.

The other half is tracking actual code changes in zic.c and localtime.c.
I don't think any of these represent near-term compatibility hazards, but
it seems best to stay up to date.

I also fixed longstanding bugs in our code for producing the
known_abbrevs.txt list, which by chance hadn't been exposed before,
but which resulted in some garbage output after applying the upstream
changes in zic.c.  Notably, because upstream removed their old phony
transitions at the Big Bang, it's now necessary to cope with TZif files
containing no DST transition times at all.

Update time zone data files to tzdata release 2018f.

DST law changes in Chile, Fiji, and Russia (Volgograd).
Historical corrections for China, Japan, Macau, and North Korea.

Note: like the previous tzdata update, this involves a depressingly
large amount of semantically-meaningless churn in tzdata.zi.  That
is a consequence of upstream's data compression method assigning
unstable abbreviations to DST rulesets.  I complained about that
to them last time, and this version now uses an assignment method
that pays some heed to not changing abbreviations unnecessarily.
So hopefully, that'll be better going forward.

Another improvement to handle multi-command queries correctly.

The new facilities in PG10 offer ways to split and detect the individual
commands in a multi-command query. But we were failing to use that correctly at
a few places. This was detected by isolation tester, but there was also an
existing bug masked by incorrect acceptance of expected output. To be fair, the
falling test case was copied to xl_known_bugs. So this was a known issue for a
while.

This now fixes the regression and isolation test.

Add missing quote_identifier calls for CREATE TRIGGER ... REFERENCING.

Mixed-case names for transition tables weren't dumped correctly.
Oversight in commit 8c48375e5, per bug #15440 from Karl Czajkowski.

In passing, I couldn't resist a bit of code beautification.

Back-patch to v10 where this was introduced.

Discussion: https://postgr.es/m/15440-02d1468e94d63d76@postgresql.org

Still further rethinking of build changes for macOS Mojave.

To avoid the sorts of problems complained of by Jakob Egger, it'd be
best if configure didn't emit any references to the sysroot path at all.
In the case of PL/Tcl, we can do that just by keeping our hands off the
TCL_INCLUDE_SPEC string altogether.  In the case of PL/Perl, we need to
substitute -iwithsysroot for -I in the compile commands, which is easily
handled if we change to using a configure output variable that includes
the switch not only the directory name.  Since PL/Tcl and PL/Python
already do it like that, this seems like good consistency cleanup anyway.

Hence, this replaces the advice given to Perl-related extensions in commit
5e2217131; instead of writing "-I$(perl_archlibexp)/CORE", they should
just write "$(perl_includespec)".  (The old way continues to work, but not
on recent macOS.)

It's still the case that configure needs to be aware of the sysroot
path internally, but that's cleaner than what we had before.

As before, back-patch to all supported versions.

Discussion: https://postgr.es/m/20840.1537850987@sss.pgh.pa.us

Temporary fix to get consistent results from ANALYZE

While we don't yet quite sure about the underlying problem, it seems that
sometimes ANALYZE fails to take into account recent updates. We suspect that
this happens because of the cluster monitor taking a little longer to report
xmin and update global xmin. For now, force a wait to get up to date stats.

Fix expected output in the 'xml' test case

Ensure that we don't try to dereference a NULL pointer

Fix minor bug in isolationtester.

If the lock wait query failed, isolationtester would report the
PQerrorMessage from some other connection, meaning there would be
no message or an unrelated one.  This seems like a pretty unlikely
occurrence, but if it did happen, this bug could make it really
difficult/confusing to figure out what happened.  That seems to
justify patching all the way back.

In passing, clean up another place where the "wrong" conn was used
for an error report.  That one's not actually buggy because it's
a different alias for the same connection, but it's still confusing
to the reader.

Improve tzparse's handling of TZDEFRULES ("posixrules") zone data.

In the IANA timezone code, tzparse() always tries to load the zone
file named by TZDEFRULES ("posixrules").  Previously, we'd hacked
that logic to skip the load in the "lastditch" code path, which we use
only to initialize the default "GMT" zone during GUC initialization.
That's critical for a couple of reasons: since we do not support leap
seconds, we *must not* allow "GMT" to have leap seconds, and since this
case runs before the GUC subsystem is fully alive, we'd really rather
not take the risk of pg_open_tzfile throwing any errors.

However, that still left the code reading TZDEFRULES on every other
call, something we'd noticed to the extent of having added code to cache
the result so it was only done once per process not a lot of times.
Andres Freund complained about the static data space used up for the
cache; but as long as the logic was like this, there was no point in
trying to get rid of that space.

We can improve matters by looking a bit more closely at what the IANA
code actually needs the TZDEFRULES data for.  One thing it does is
that if "posixrules" is a leap-second-aware zone, the leap-second
behavior will be absorbed into every POSIX-style zone specification.
However, that's a behavior we'd really prefer to do without, since
for our purposes the end effect is to render every POSIX-style zone
name unsupported.  Otherwise, the TZDEFRULES data is used only if
the POSIX zone name specifies DST but doesn't include a transition
date rule (e.g., "EST5EDT" rather than "EST5EDT,M3.2.0,M11.1.0").
That is a minority case for our purposes --- in particular, it
never happens when tzload() invokes tzparse() to interpret a
transition date rule string found in a tzdata zone file.

Hence, if we legislate that we're going to ignore leap-second data
from "posixrules", we can postpone the TZDEFRULES load into the path
where we actually need to substitute for a missing date rule string.
That means it will never happen at all in common scenarios, making it
reasonable to dynamically allocate the cache space when it does happen.
Even when the data is already loaded, this saves some cycles in the
common code path since we avoid a memcpy of 23KB or so.  And, IMO at
least, this is a less ugly hack on the IANA logic than what we had
before, since it's not messing with the lastditch-vs-regular code paths.

Back-patch to all supported branches, not so much because this is a
critical change as that I want to keep all our copies of the IANA
timezone code in sync.

Discussion: https://postgr.es/m/20181015200754[email protected]

Back off using -isysroot on Darwin.

Rethink the solution applied in commit 5e2217131 to get PL/Tcl to
build on macOS Mojave.  I feared that adding -isysroot globally might
have undesirable consequences, and sure enough Jakob Egger reported
one: it complicates building extensions with a different Xcode version
than was used for the core server.  (I find that a risky proposition
in general, but apparently it works most of the time, so we shouldn't
break it if we don't have to.)

We'd already adopted the solution for PL/Perl of inserting the sysroot
path directly into the -I switches used to find Perl's headers, and we
can do the same thing for PL/Tcl by changing the -iwithsysroot switch
that Apple's tclConfig.sh reports.  This restricts the risks to PL/Perl
and PL/Tcl themselves and directly-dependent extensions, which is a lot
more pleasing in general than a global -isysroot switch.

Along the way, tighten the test to see if we need to inject the sysroot
path into $perl_includedir, as I'd speculated about upthread but not
gotten round to doing.

As before, back-patch to all supported versions.

Discussion: https://postgr.es/m/20840.1537850987@sss.pgh.pa.us

Avoid rare race condition in privileges.sql regression test.

We created a temp table, then switched to a new session, leaving
the old session to clean up its temp objects in background.  If that
took long enough, the eventual attempt to drop the user that owns
the temp table could fail, as exhibited today by sidewinder.
Fix by dropping the temp table explicitly when we're done with it.

It's been like this for quite some time, so back-patch to all
supported branches.

Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sidewinder&dt=2018-10-16%2014%3A45%3A00

Make PostgresNode.pm's poll_query_until() more chatty about failures.

Reporting only the stderr is unhelpful when the problem is that the
server output we're getting doesn't match what was expected.  So we
should report the query output too; and just for good measure, let's
print the query we used and the output we expected.

Back-patch to 9.5 where poll_query_until was introduced.

Discussion: https://postgr.es/m/17913.1539634756@sss.pgh.pa.us

Improve stability of recently-added regression test case.

Commit b5febc1d1 added a contrib/btree_gist test case that has been
observed to fail in the buildfarm as a result of background auto-analyze
updating stats and changing the selected plan.  Forestall that by
forcibly analyzing in foreground, instead.  The new plan choice is
just as good for our purposes, since we really only care that an
index-only plan does not get selected.

Back-patch to 9.5, like the previous patch.

Discussion: https://postgr.es/m/14643.1539629304@sss.pgh.pa.us

Avoid statically allocating gmtsub()'s timezone workspace.

localtime.c's "struct state" is a rather large object, ~23KB.  We were
statically allocating one for gmtsub() to use to represent the GMT
timezone, even though that function is not at all heavily used and is
never reached in most backends.  Let's malloc it on-demand, instead.

This does pose the question of how to handle a malloc failure, but
there's already a well-defined error report convention here, ie
set errno and return NULL.

We have but one caller of pg_gmtime in HEAD, and two in back branches,
neither of which were troubling to check for error.  Make them do so.
The possible errors are sufficiently unlikely (out-of-range timestamp,
and now malloc failure) that I think elog() is adequate.

Back-patch to all supported branches to keep our copies of the IANA
timezone code in sync.  This particular change is in a stanza that
already differs from upstream, so it's a wash for maintenance purposes
--- but only as long as we keep the branches the same.

Discussion: https://postgr.es/m/20181015200754[email protected]

Check for stack overrun in standard_ProcessUtility().

ProcessUtility can recurse, and indeed can be driven to infinite
recursion, so it ought to have a check_stack_depth() call.  This
covers the reported bug (portal trying to execute itself) and a bunch
of other cases that could perhaps arise somewhere.

Per bug #15428 from Malthe Borch.  Back-patch to all supported branches.

Discussion: https://postgr.es/m/15428-b3c2915ec470b033@postgresql.org

Fix couple of regressions introduced in the previous commit.

The format of the GTM control file setup during `initgtm` was broken. Also, we
failed to consider the case of GTM standby initialising which might pass a NULL
File handle.

contrib/bloom documentation improvement

This commit documents rounding of "length" parameter and absence of support
for unique indexes and NULLs searching.  Backpatch to 9.6 where contrib/bloom
was introduced.

Discussion: https://postgr.es/m/CAF4Au4wPQQ7EHVSnzcLjsbY3oLSzVk6UemZLD1Sbmwysy3R61g%40mail.gmail.com
Author: Oleg Bartunov with minor editorialization by me
Backpatch-through: 9.6

Avoid duplicate XIDs at recovery when building initial snapshot

On a primary, sets of XLOG_RUNNING_XACTS records are generated on a
periodic basis to allow recovery to build the initial state of
transactions for a hot standby.  The set of transaction IDs is created
by scanning all the entries in ProcArray.  However it happens that its
logic never counted on the fact that two-phase transactions finishing to
prepare can put ProcArray in a state where there are two entries with
the same transaction ID, one for the initial transaction which gets
cleared when prepare finishes, and a second, dummy, entry to track that
the transaction is still running after prepare finishes.  This way
ensures a continuous presence of the transaction so as callers of for
example TransactionIdIsInProgress() are always able to see it as alive.

So, if a XLOG_RUNNING_XACTS takes a standby snapshot while a two-phase
transaction finishes to prepare, the record can finish with duplicated
XIDs, which is a state expected by design.  If this record gets applied
on a standby to initial its recovery state, then it would simply fail,
so the odds of facing this failure are very low in practice.  It would
be tempting to change the generation of XLOG_RUNNING_XACTS so as
duplicates are removed on the source, but this requires to hold on
ProcArrayLock for longer and this would impact all workloads,
particularly those using heavily two-phase transactions.

XLOG_RUNNING_XACTS is also actually used only to initialize the standby
state at recovery, so instead the solution is taken to discard
duplicates when applying the initial snapshot.

Diagnosed-by: Konstantin Knizhnik
Author: Michael Paquier
Discussion: https://postgr.es/m/0c96b653-4696-d4b4-6b5d-78143175d113@postgrespro.ru
Backpatch-through: 9.3

Remove abstime, reltime, tinterval tables from old regression databases.

In the back branches, drop these tables after the regression tests are
done with them.  This fixes failures of cross-branch pg_upgrade testing
caused by these types having been removed in v12.  We do lose the ability
to test dump/restore behavior with these types in the back branches, but
the actual loss of code coverage seems to be nil given that there's nothing
very special about these types.

Discussion: https://postgr.es/m/20181009192237[email protected]

Fix incorrect comparison in pgxcnode_gethash

The check is supposed to ensure NULL/empty nodename gets hashed to 0,
but (nodename == '\0') is comparing the pointer itself, not the first
character. So dereference that correctly.

Use sufficiently large buffer in SharedQueueWrite

The sq_key alone may be up to 64 bytes, so we need more than that.
We could use dynamic memory instead, but 128 bytes should be enough
both for the sq_key and the other pieces.

Use dynamic buffer to parse NODE_LIST_RESULT in GTM

When processing NODE_LIST_RESULT messages, gtmpqParseSuccess() used
a static buffer, defined as "char buf[8092]".  This is an issue, as
the message has variable length, and may get long enough to exceed
any hard-coded limit.  While that's not very common (it requires
long paths, node names and/or many GTM sessions on the node), it
may happen, in which case the memcpy() causes a buffer overflow and
corrupts the stack.

Fixing this is simple - allocate the buffer using malloc() intead,
requesting exactly the right amount of memory.  This however hits
a latent pre-existing issue in the code, because the code was doing
memcpy(&buf,...) instead of memcpy(buf,...).  With static buffers
this was harmless, because (buf == &buf), so the code was working
as intended (except when there were more than 8092 bytes).  With
dynamic memory this is no longer true, becase (buf != &buf), and
the stack corruption was much easier to trigger (just 8 bytes).

Per report and debug info by Hengbing. Patch by Pavan and me.

Fix logical decoding error when system table w/ toast is repeatedly rewritten.

Repeatedly rewriting a mapped catalog table with VACUUM FULL or
CLUSTER could cause logical decoding to fail with:
ERROR, "could not map filenode \"%s\" to relation OID"

To trigger the problem the rewritten catalog had to have live tuples
with toasted columns.

The problem was triggered as during catalog table rewrites the
heap_insert() check that prevents logical decoding information to be
emitted for system catalogs, failed to treat the new heap's toast table
as a system catalog (because the new heap is not recognized as a
catalog table via RelationIsLogicallyLogged()). The relmapper, in
contrast to the normal catalog contents, does not contain historical
information. After a single rewrite of a mapped table the new relation
is known to the relmapper, but if the table is rewritten twice before
logical decoding occurs, the relfilenode cannot be mapped to a
relation anymore.  Which then leads us to error out.   This only
happens for toast tables, because the main table contents aren't
re-inserted with heap_insert().

The fix is simple, add a new heap_insert() flag that prevents logical
decoding information from being emitted, and accept during decoding
that there might not be tuple data for toast tables.

Unfortunately that does not fix pre-existing logical decoding
errors. Doing so would require not throwing an error when a filenode
cannot be mapped to a relation during decoding, and that seems too
likely to hide bugs.  If it's crucial to fix decoding for an existing
slot, temporarily changing the ERROR in ReorderBufferCommit() to a
WARNING appears to be the best fix.

Author: Andres Freund
Discussion: https://postgr.es/m/20180914021046[email protected]
Backpatch: 9.4-, where logical decoding was introduced

Ensure CREATE TABLE (LIKE INCLUDING ALL) honors distribution strategy

We introduce two INCLUDING/EXCLUDING options to copy the distribution strategy
and the target nodes. It's quite unlikely that someone would create a LIKE
table but won't want to copy the distribution information, but it gives user
flexibility to do that. Since we did not want to add more keywords, we simply
used DISTRIBUTE and NODE, though DISTRIBUTION and NODES may have been better
names.

Wake up cluster monitor more aggressively when a backend is waiting

When a backend is waiting for another transaction to commit on the GTM, it
wakes up the cluster monitor process before going to sleep. This ensures that
the backend gets to know about transaction completion much sooner. This
mechanism shouldn't be too bad because a backend potentially may wait on
the global commit only after the transaction is locally committed. Hence in
most common cases, the wait shouldn't be too long.

Per report from Hengbing on the last patch.

Track global GTM state via cluster monitor.

We received a report that sometimes a transaction fails to see a recently
committed row, especially when the query tries to insert a duplicate primary
key, sees another concurrent insert and then waits for the other transaction to
commit. The next statement in the transaction should see the concurrently
inserted row if the transaction is running in read committed mode. But in
practice, sometimes GTM may see the final COMMIT message of the second
transaction after it hands out a new snapshot to the first transaction and this
snapshot still shows the second transaction as running. The MVCC check then
fails to see the row.

This is quite a complex situation and a tricky one to handle in a distributed
system without some kind of logical ordering of events. For example, if a
transaction T1 sees a COMMIT of another transaction T2 anywhere in the cluster,
all subsequent actions of T1 should see T2's COMMIT. Enforcing such logical
ordering is not trivial without additional communication overhead.

So what we are now doing is to ensure that a transaction is reported as
in-progress on all nodes until the GTM sees the final COMMIT. But instead of
querying the GTM everytime, we now maintain a local copy of the GTM's view of
running transactions. This local copy is either updated by the cluster-monitor
proccess at regular interval or when other backends fetch a new snapshot from
the GTM. In order to ensure that the state is only moved forward, we now also
have a concept of snapshot_id or counter which is incremented everytime state
on the GTM changes. Being a 64-bit counter, we don't need to worry about
a wrap-around. A transaction is considered to be in-progress, as long as it's
open on the GTM.

Accept changes in xc_for_update test case's expected output. In fact, the old
output was wrong since we were disregarding the prepared transaction holding
the AEL on the table. This looks like a separate bug, which should be
investigated in more details.

Harden the rules for GTM control file structure

We introduced GTM control file version in commit d372df43649, way back in
2016-03-02. But in order to support the older version, we were accepting any
bad input and overwriting the control file with initial data. This can lead to
many issues. Hence stop accepting bad version or bad contents. This should
hopefully be not a problem since we're working on a new XL 10 release. And even
if we backpatch this to XL 9.5, it shouldn't cause too much problem as the
version change was introduced before XL 9.5 GA.

We need to work on this more by adding even more stricter checks for control
file sanity, including CRC checksums. But that can happen via a separate
commit.

Silence compiler warning in Assert()

gcc 6.3 does not whine about this mistake I made in 39808e8868c8 but
evidently lots of other compilers do, according to Michael Paquier,
Peter Eisentraut, Arthur Zakirov, Tomas Vondra.

Discussion: too many to list

Add regression test for ATTACH PARTITION

This test case uses a SQL function as partitioning operator, whose
evaluation results in the table's relcache being rebuilt partway
through the execution of an ATTACH PARTITION command.

It is extracted from 39808e8, which fixed a bug where this test case
failed on master and REL_11_STABLE, but passed on REL_10_STABLE.  The
partitioning code has changed a lot during v11 development, so this
makes sure that any patch applied to REL_10_STABLE fixing a
partition-related bug does not break it again.

Author: Amit Langote
Reviewed-by: Michaël Paquier, Álvaro Herrera
Discussion: https://postgr.es/m/CAKcux6=nTz9KSfTr_6Z2mpzLJ_09JN-rK6=dWic6gGyTSWueyQ@mail.gmail.com

Fix event triggers for partitioned tables

Index DDL cascading on partitioned tables introduced a way for ALTER
TABLE to be called reentrantly.  This caused an an important deficiency
in event trigger support to be exposed: on exiting the reentrant call,
the alter table state object was clobbered, causing a crash when the
outer alter table tries to finalize its processing.  Fix the crash by
creating a stack of event trigger state objects.  There are still ways
to cause things to misbehave (and probably other crashers) with more
elaborate tricks, but at least it now doesn't crash in the obvious
scenario.

Backpatch to 9.5, where DDL deparsing of event triggers was introduced.

Reported-by: Marco Slot
Authors: Michaël Paquier, Álvaro Herrera
Discussion: https://postgr.es/m/CANNhMLCpi+HQ7M36uPfGbJZEQLyTy7XvX=5EFkpR-b1bo0uJew@mail.gmail.com

Propagate xactStartTimestamp and stmtStartTimestamp to parallel workers.

Previously, a worker process would establish values for these based on
its own start time.  In v10 and up, this can trivially be shown to cause
misbehavior of transaction_timestamp(), timestamp_in(), and related
functions which are (perhaps unwisely?) marked parallel-safe.  It seems
likely that other behaviors might diverge from what happens in the parent
as well.

It's not as trivial to demonstrate problems in 9.6 or 9.5, but I'm sure
it's still possible, so back-patch to all branches containing parallel
worker infrastructure.

In HEAD only, mark now() and statement_timestamp() as parallel-safe
(other affected functions already were).  While in theory we could
still squeeze that change into v11, it doesn't seem important enough
to force a last-minute catversion bump.

Konstantin Knizhnik, whacked around a bit by me

Discussion: https://postgr.es/m/6406dbd2-5d37-4cb6-6eb2-9c44172c7e7c@postgrespro.ru

Allow btree comparison functions to return INT_MIN.

Historically we forbade datatype-specific comparison functions from
returning INT_MIN, so that it would be safe to invert the sort order
just by negating the comparison result.  However, this was never
really safe for comparison functions that directly return the result
of memcmp(), strcmp(), etc, as POSIX doesn't place any such restriction
on those library functions.  Buildfarm results show that at least on
recent Linux on s390x, memcmp() actually does return INT_MIN sometimes,
causing sort failures.

The agreed-on answer is to remove this restriction and fix relevant
call sites to not make such an assumption; code such as "res = -res"
should be replaced by "INVERT_COMPARE_RESULT(res)".  The same is needed
in a few places that just directly negated the result of memcmp or
strcmp.

To help find places having this problem, I've also added a compile option
to nbtcompare.c that causes some of the commonly used comparators to
return INT_MIN/INT_MAX instead of their usual -1/+1.  It'd likely be
a good idea to have at least one buildfarm member running with
"-DSTRESS_SORT_INT_MIN".  That's far from a complete test of course,
but it should help to prevent fresh introductions of such bugs.

This is a longstanding portability hazard, so back-patch to all supported
branches.

Discussion: https://postgr.es/m/20180928185215[email protected]

Relax restriction for column ordering for partition tables

We'd put a overly restrictive limitation that the column orders and column
positions must match between a partitioned table and it's children. This was
done during the PG 10 merge while we were still fixing many other issues. But
now is the right time to revisit this restriction. While we still need to
ensure that the distribution column's type, name and position matches across
all tables, we can relax the restriction for other columns. This should help in
a common situation where columns are added and dropped in the parent table. As
long as the physical position of the distribution column does not change, one
should now be able to create a child table and attach it as a partition without
worrying too much about dropped columns. Many other restrictions still apply as
they do in PostgreSQL.

A few test cases are added to test the new behaviour.

MAXALIGN the target address where we store flattened value.

The API (EOH_flatten_into) that flattens the expanded value representation
expects the target address to be maxaligned.  All it's usage adhere to that
principle except when serializing datums for parallel query.  Fix that
usage.

Diagnosed-by: Tom Lane
Author: Tom Lane and Amit Kapila
Backpatch-through: 9.6
Discussion: https://postgr.es/m/11629.1536550032@sss.pgh.pa.us

Set snprintf.c's maximum number of NL arguments to be 31.

Previously, we used the platform's NL_ARGMAX if any, otherwise 16.
The trouble with this is that the platform value is hugely variable,
ranging from the POSIX-minimum 9 to as much as 64K on recent FreeBSD.
Values of more than a dozen or two have no practical use and slow down
the initialization of the argtypes array.  Worse, they cause snprintf.c
to consume far more stack space than was the design intention, possibly
resulting in stack-overflow crashes.

Standardize on 31, which is comfortably more than we need (it looks like
no existing translatable message has more than about 10 parameters).
I chose that, not 32, to make the array sizes powers of 2, for some
possible small gain in speed of the memset.

The lack of reported crashes suggests that the set of platforms we
use snprintf.c on (in released branches) may have no overlap with
the set where NL_ARGMAX has unreasonably large values.  But that's
not entirely clear, so back-patch to all supported branches.

Per report from Mateusz Guzik (via Thomas Munro).

Discussion: https://postgr.es/m/CAEepm=3VF=PUp2f8gU8fgZB22yPE_KBS0+e1AHAtQ=09schTHg@mail.gmail.com

Fix corner-case failures in has_foo_privilege() family of functions.

The variants of these functions that take numeric inputs (OIDs or
column numbers) are supposed to return NULL rather than failing
on bad input; this rule reduces problems with snapshot skew when
queries apply the functions to all rows of a catalog.

has_column_privilege() had careless handling of the case where the
table OID didn't exist.  You might get something like this:
select has_column_privilege(9999,'nosuchcol','select');
ERROR:  column "nosuchcol" of relation "(null)" does not exist
or you might get a crash, depending on the platform's printf's response
to a null string pointer.

In addition, while applying the column-number variant to a dropped
column returned NULL as desired, applying the column-name variant
did not:
select has_column_privilege('mytable','........pg.dropped.2........','select');
ERROR:  column "........pg.dropped.2........" of relation "mytable" does not exist
It seems better to make this case return NULL as well.

Also, the OID-accepting variants of has_foreign_data_wrapper_privilege,
has_server_privilege, and has_tablespace_privilege didn't follow the
principle of returning NULL for nonexistent OIDs.  Superusers got TRUE,
everybody else got an error.

Per investigation of Jaime Casanova's report of a new crash in HEAD.
These behaviors have been like this for a long time, so back-patch to
all supported branches.

Patch by me; thanks to Stephen Frost for discussion and review

Discussion: https://postgr.es/m/CAJGNTeP=-6Gyqq5TN9OvYEydi7Fv1oGyYj650LGTnW44oAzYCg@mail.gmail.com

Fix documentation of pgrowlocks using "lock_type" instead of "modes"

The example used in the documentation is outdated as well.  This is an
oversight from 0ac5ad5, which bumped up pgrowlocks but forgot some bits
of the documentation.

Reported-by: Chris Wilson
Discussion: https://postgr.es/m/153838692816.2950.12001142346234155699@wrigleys.postgresql.org
Backpatch-through: 9.3

Fix tuple_data_split() to not open a relation without any lock.

contrib/pageinspect's tuple_data_split() function thought it could get
away with opening the referenced relation with NoLock.  In practice
there's no guarantee that the current session holds any lock on that
rel (even if we just read a page from it), so that this is unsafe.

Switch to using AccessShareLock.  Also, postpone closing the relation,
so that we needn't copy its tupdesc.  Also, fix unsafe use of
att_isnull() for attributes past the end of the tuple.

Per testing with a patch that complains if we open a relation without
holding any lock on it.  I don't plan to back-patch that patch, but we
should close the holes it identifies in all supported branches.

Discussion: https://postgr.es/m/2038.1538335244@sss.pgh.pa.us

Fix ALTER COLUMN TYPE to not open a relation without any lock.

If the column being modified is referenced by a foreign key constraint
of another table, ALTER TABLE would open the other table (to re-parse
the constraint's definition) without having first obtained a lock on it.
This was evidently intentional, but that doesn't mean it's really safe.
It's especially not safe in 9.3, which pre-dates use of MVCC scans for
catalog reads, but even in current releases it doesn't seem like a good
idea.

We know we'll need AccessExclusiveLock shortly to drop the obsoleted
constraint, so just get that a little sooner to close the hole.

Per testing with a patch that complains if we open a relation without
holding any lock on it.  I don't plan to back-patch that patch, but we
should close the holes it identifies in all supported branches.

Discussion: https://postgr.es/m/2038.1538335244@sss.pgh.pa.us

Fix detection of the result type of strerror_r().

The method we've traditionally used, of redeclaring strerror_r() to
see if the compiler complains of inconsistent declarations, turns out
not to work reliably because some compilers only report a warning,
not an error.  Amazingly, this has gone undetected for years, even
though it certainly breaks our detection of whether strerror_r
succeeded.

Let's instead test whether the compiler will take the result of
strerror_r() as a switch() argument.  It's possible this won't
work universally either, but it's the best idea I could come up with
on the spur of the moment.

Back-patch of commit 751f532b9.  Buildfarm results indicate that only
icc-on-Linux actually has an issue here; perhaps the lack of field
reports indicates that people don't build PG for production that way.

Discussion: https://postgr.es/m/10877.1537993279@sss.pgh.pa.us

Fix assertion failure when updating full_page_writes for checkpointer.

When the checkpointer receives a SIGHUP signal to update its configuration,
it may need to update the shared memory for full_page_writes and need to
write a WAL record for it.  Now, it is quite possible that the XLOG
machinery has not been initialized by that time and it will lead to
assertion failure while doing that.  Fix is to allow the initialization of
the XLOG machinery outside critical section.

This bug has been introduced by the commit 2c03216d83 which added the XLOG
machinery initialization in RecoveryInProgress code path.

Reported-by: Dilip Kumar
Author: Dilip Kumar
Reviewed-by: Michael Paquier and Amit Kapila
Backpatch-through: 9.5
Discussion: https://postgr.es/m/CAFiTN-u4BA8KXcQUWDPNgaKAjDXC=C2whnzBM8TAcv=stckYUw@mail.gmail.com

Ensure config changes caused by functions are rolled back correctly.

When a function body has SET clauses attached to it, the function
validation/execution reflects those config changes locally as well as on the
remote nodes. But we were failing to restore the old values back when the
command ends. This had gone unnoticed so far for the lack of any test case
exercising this code. Note that there were existing test cases in this area,
but the bug got unmasked only after we added a temporary table in the session.
When a temporary table is accessed in a session, we don't reset the session at
the end of the transaction and hence the issue surfaced.

This was causing failure in a new test added in the 'rules' test. This patch
fixes that.

Accept regression diffs in 'object_address' test case.

The differences are caused by our lack of support for CREATE
SUBSCRIPTION/PUBLICATION

Accept regression diffs in 'portal' test case.

One change relates to the addition of Remote Subplan node and the other relates
to our lack of support for WHERE CURRENT OF

Fix an oversight in c8a42a0726911b737837d6763707c7d14d9a2987

Well spotted by Virendra Kumar

Some edits to a TAP test

Minor refactoring of the code to send down SET options

Fix WAL recycling on standbys depending on archive_mode

A restart point or a checkpoint recycling WAL segments treats segments
marked with neither ".done" (archiving is done) or ".ready" (segment is
ready to be archived) in archive_status the same way for archive_mode
being "on" or "always".  While for a primary this is fine, a standby
running a restart point with archive_mode = on would try to mark such a
segment as ready for archiving, which is something that will never
happen except after the standby is promoted.

Note that this problem applies only to WAL segments coming from the
local pg_wal the first time archive recovery is run.  Segments part of a
self-contained base backup are the most common case where this could
happen, however even in this case normally the .done markers would be
most likely part of the backup.  Segments recovered from an archive are
marked as .ready or .done by the startup process, and segments finished
streaming are marked as such by the WAL receiver, so they are handled
already.

Reported-by: Haruka Takatsuka
Author: Michael Paquier
Discussion: https://postgr.es/m/15402-a453c90ed4cf88b2@postgresql.org
Backpatch-through: 9.5, where archive_mode = always has been added.

Fix assorted bugs in pg_get_partition_constraintdef().

It failed if passed a nonexistent relation OID, or one that was a non-heap
relation, because of blindly applying heap_open to a user-supplied OID.
This is not OK behavior for a SQL-exposed function; we have a project
policy that we should return NULL in such cases.  Moreover, since
pg_get_partition_constraintdef ought now to work on indexes, restricting
it to heaps is flat wrong anyway.

The underlying function generate_partition_qual() wasn't on board with
indexes having partition quals either, nor for that matter with rels
having relispartition set but yet null relpartbound.  (One wonders
whether the person who wrote the function comment blocks claiming that
these functions allow a missing relpartbound had ever tested it.)

Fix by testing relispartition before opening the rel, and by using
relation_open not heap_open.  (If any other relkinds ever grow the
ability to have relispartition set, the code will work with them
automatically.)  Also, don't reject null relpartbound in
generate_partition_qual.

Back-patch to v11, and all but the null-relpartbound change to v10.
(It's not really necessary to change generate_partition_qual at all
in v10, but I thought s/heap_open/relation_open/ would be a good
idea anyway just to keep the code in sync with later branches.)

Per report from Justin Pryzby.

Discussion: https://postgr.es/m/20180927200020[email protected]

Add a TAP test to do sanity tests post addition of coordinators/datanodes.

Its a very simplistic test right now, but hopefully we can extend this further
in the coming time.

Recurse to sequences on ownership change for all relkinds

When a table ownership is changed, we must apply that also to any owned
sequences.  (Otherwise, it would result in a situation that cannot be
restored, because linked sequences must have the same owner as the
table.)  But this was previously only applied to regular tables and
materialized views.  But it should also apply to at least foreign
tables.  This patch removes the relkind check altogether, because it
doesn't save very much and just introduces the possibility of similar
omissions.

Bug: #15238
Reported-by: Christoph Berg <[email protected]>

Use read-write transaction to dump a database

In XL we use nextval() to get a consistent value of a sequence since different
nodes may have stale view of the sequence and hence we must obtain a value from
the GTM. Calling nextval() though requires us to execute the transaction in
read-write mode. So we do that. It shouldn't be a big deal since pg_dump is
very careful about only reading from the database (it was only recently the
transaction was made read-only). More to the point, in XL we'd never used
read-only transaction while dumping a database, but by default direct
connection to a datanode are treated as read-only transaction and hence merely
removing READ ONLY transaction attribute wasn't enough. We had to explicitly
mark it READ WRITE to override the default datanode behaviour.

Per report by Virendra Kumar

Accept regression diff in 'xml' test case casued by merge issue

Accept regression diffs arising due to lack of FDW support