Previously a tuple that has been moved to a different partition (see
f16241be), set the block number on the old tuple to an invalid
value to indicate that fact. But the tuple offset was left
untouched. That turned out to trigger a wal_consistency_checking
failure as reported by Peter Geoghegan, as the offset wasn't
always overwritten during WAL replay.

Heikki observed that we're wasting valuable data by not putting
information also in the offset. Thus set that to
MovedPartitionsOffsetNumber when a tuple indicates it has moved.

We continue to set the block number to MovedPartitionsBlockNumber, as
that seems more likely to cause problems for code not updated to know
about moved tuples.

As t_ctid's offset number is now always set, this refinement also
fixes the wal_consistency_checking issue.

This technically is a minor disk format break, with previously created
moved tuples not being recognized anymore. But since there not even
has been a beta release since f16241be...

Reported-By: Peter Geoghegan
Author: Heikki Linnakangas, Amul Sul
Discussion: https://postgr.es/m/CAH2-Wzm9ty+1BX7-GMNJ=xPRg67oJTVeDNdA9LSyJJtMgRiCMA@mail.gmail.com

Without these fixes, changes to the inserted tuple made by remote
triggers are ignored when building local RETURNING tuples.

In the core code, call ExecInitRoutingInfo at a later point from
within ExecInitPartitionInfo so that the FDW callback gets invoked
after the returning list has been built.  But move CheckValidResultRel
out of ExecInitRoutingInfo so that it can happen at an earlier stage.

In postgres_fdw, refactor assorted deparsing functions to work with
the RTE rather than the PlannerInfo, which saves us having to
construct a fake PlannerInfo in cases where we don't have a real one.
Then, we can pass down a constructed RTE that yields the correct
deparse result when no real one exists.  Unfortunately, this
necessitates a hack that understands how the core code manages RT
indexes for update tuple routing, which is ugly, but we don't have a
better idea right now.

Original report, analysis, and patch by Etsuro Fujita.  Heavily
refactored by me.  Then worked over some more by Amit Langote.

Discussion: http://postgr.es/m/5AD4882B.10002@lab.ntt.co.jp

It turns out that old Perl versions (before about 5.10) don't have any
very reliable way to generate Inf or NaN numeric values.  Getting around
that would require way more work than is really justified to test the
code involved, so let's just drop these new test cases.

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

Revert commits 23078689, 73042b8d, ce07aff4, f7df8043, 6ba0cc4b,
eb16011f, 68e7e973, 63ca350e.  We still have a problem here, but
somebody who's actually a Windows developer will need to spend time
on it.

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

Back branches still are SGML.

David Rowley, Amit Langote

The previous coding here didn't actually produce Inf or NaN double
values in Perl versions 5.8.x.  Adopt a suggestion from stackoverflow.

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

Revert the map/unmap dance I tried in commit 73042b8d; that helps
not at all.

Instead, speculate that the unwanted allocation is being done on
another thread, and thus timing variations explain the apparent
unpredictability.  Temporarily add a 1-second sleep before the
VirtualFree call, in hopes that any such other threads will
quiesce and not jog our elbow.

This is obviously not a desirable long-term fix, but as a means of
investigation it seems useful.

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

The idea here is to get Windows' userspace infrastructure to allocate
whatever space it needs for MapViewOfFileEx() before we release the
locked-down space that we want to map the shared memory block into.

This is a fairly brute-force attempt, and would likely (for example)
fail with large shared memory on 32-bit Windows.  We could perhaps
ameliorate that by mapping only part of the shared memory block in
this way, but for the moment I just want to see if this approach
will fix dory's problem.

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

Rather than elog'ing immediately, push the map data into a preallocated
StringInfo.  Perhaps this will prevent some of the mid-operation
allocations that are evidently happening now.

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

The code previously undefined isnan because of a compiler warning on
MinGW.  Since we now need to use isnan, we can't do that anymore.

We might need a different solution if the compiler warning is too
annoying.

So by default, they don't output anything if everything is well.

Discussion: https://www.postgresql.org/message-id/867f8a1a-6cf0-d835-78d8-0844e4936241%402ndquadrant.com

When due to publication configuration, a TRUNCATE change ends up with
zero tables to be published, don't send the message out, just skip it.
It's not wrong, but obviously useless overhead.

jsonb uses numeric internally, and numeric can store NaN, but that is
not allowed by jsonb on input, so we shouldn't store it.  Also prevent
infinity to get a consistent error message.  (numeric input would reject
infinity anyway.)
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>

This code is evidently allocating memory and thus confusing matters
even more.  Let's see whether we can learn anything with
just VirtualQuery.

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

This morning's results from buildfarm member dory make it pretty
clear that something is getting mapped into the just-freed space,
but not what that something is.  Replace my minimalistic probes
with a full dump of the process address space and module space,
based on Noah's work at
<20170403065106.GA2624300%40tornado.leadboat.com>

This is all (probably) to get reverted once we have fixed the
problem, but for now we need information.

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

While looking at a recent buildfarm failure in the ecpg tests, I wondered
why the pg_regress output claimed the stderr part of the test failed, when
the regression diffs were clearly for the stdout part.  Looking into it,
the reason is that pg_regress.c's logic for iterating over three parallel
lists is wrong, and has been wrong since it was written: it advances the
"tag" pointer at a different place in the loop than the other two pointers.
Fix that.

After some thought about the info captured so far, it seems possible
that MapViewOfFileEx is itself causing some DLL to get loaded into
the space just freed by VirtualFree.  The previous commit here didn't
capture enough info to really prove the case for that, so let's add
one more VirtualQuery in between those steps.  Also, be sure to
capture the post-Map state before we emit any log entries, just in
case elog() is invoking some code not previously loaded.

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

Buildfarm results show that the modern POSIX rule that 1 ^ NaN = 1 is not
honored on *BSD until relatively recently, and really old platforms don't
believe that NaN ^ 0 = 1 either.  (This is unsurprising, perhaps, since
SUSv2 doesn't require either behavior.)  In hopes of getting to platform
independent behavior, let's deal with all the NaN-input cases explicitly
in dpow().

Note that numeric_power() doesn't know either of these special cases.
But since that behavior is platform-independent, I think it should be
addressed separately, and probably not back-patched.

Discussion: https://postgr.es/m/75DB81BEEA95B445AE6D576A0A5C9E936A73E741@BPXM05GP.gisp.nec.co.jp

Commit 63ca350e neglected to probe the state of things *before*
the VirtualFree call, which now looks like it might be interesting.

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

DST law changes in Palestine and Antarctica (Casey Station).  Historical
corrections for Portugal and its colonies, as well as Enderbury, Jamaica,
Turks & Caicos Islands, and Uruguay.

Per spec, the result of power() should be NaN if either input is NaN.
It appears that on some versions of Windows, the libc function does
return NaN, but it also sets errno = EDOM, confusing our code that
attempts to work around shortcomings of other platforms.  Hence, add
guard tests to avoid substituting a wrong result for the right one.

It's been like this for a long time (and the odd behavior only appears
in older MSVC releases, too) so back-patch to all supported branches.

Dang Minh Huong, reviewed by David Rowley

Discussion: https://postgr.es/m/75DB81BEEA95B445AE6D576A0A5C9E936A73E741@BPXM05GP.gisp.nec.co.jp

The point of this is not really to remove redundancy in pg_language.dat;
with only three entries, it's hardly worth it.  Rather, it is to get
to a point where there are exactly zero hard-coded numeric pg_proc OID
references in the catalog .dat files.  The lanvalidator column was the
only remaining location of such references, and it seems like a good
thing for future-proofing reasons to make it not be a special case.

There are still a few places in the .dat files with numeric OID references
to other catalogs, but after review I don't see any that seem worth
changing at present.  In each case there are just too few entries to make
it worth the trouble to create lookup infrastructure.

This doesn't change the emitted postgres.bki file, so no catversion bump.

This change makes this module act more like most of our other low-level
resource management modules.  It's a caller error if something is not
explicitly closed by the end of a successful transaction, so issue
a WARNING about it.  This would not actually have caught the file leak
bug fixed in commit 231bcd08, because that was in a transaction-abort
path; but it still seems like a good, and pretty cheap, cross-check.

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

This field was a bool at one point, but now it's an int.
Spotted by Hari Babu; trivial patch is by Ashutosh Bapat.

Discussion: https://postgr.es/m/CAJrrPGedKiFE2fqntSauUfhapCksOJzam+QtHfSgx86LhXLeOQ@mail.gmail.com

Use the same code we already applied in duplicate_oids and unused_oids
to let this script find Catalog.pm without help.  This removes the need
to supply a -I switch in most cases.

Also, mark the script executable, again to follow the precedent of
duplicate_oids and unused_oids.  Now you can just do
"./reformat_dat_file.pl pg_proc.dat"
if you want to reformat only one or a few .dat files rather than all.

It'd be possible to remove the -I switches in the Makefile's convenience
targets, but I chose to leave them: they don't hurt anything, and it's
possible that in weird VPATH situations they might be of value.

I (tgl) originally coded the special case for pg_proc.pronargs as
though it were a kind of default value.  It seems better though to
treat computable columns as an independent concern: this makes the
code clearer, and probably a bit faster too since we needn't do
work inside the per-column loop.

Improve related comments, as well, in the expectation that there
might be more cases like this in future.

John Naylor, some additional comment-hacking by me

Discussion: https://postgr.es/m/CAJVSVGW-D7OobzU=dybVT2JqZAx-4X1yvBJdavBmqQL05Q6CLw@mail.gmail.com

Apparently $(foreach ... $(call install_llvm_module,...)) doesn't work
too well without a blank line ending the install_llvm_module macro.
The previous coding hackishly dodged this problem with some parens,
but that's not really a good solution because make misunderstands
where the command boundaries are that way.

Discussion: https://postgr.es/m/20180428073935.GB1736@paquier.xyz

Don't put comments inside the macros, per complaint from Michael Paquier.

Quote target directory path with single quotes, not double; that seems
to be our project standard.  Not quoting it at all definitely isn't
per standard.

Remove excess slash in one instance of path.

Remove useless semicolon.

Discussion: https://postgr.es/m/20180428073935.GB1736@paquier.xyz

Identify pg_replication_origin as a shared catalog in catalogs.sgml,
using the same boilerplate wording used for most other shared catalogs
(and tweak another place where someone had randomly deviated from
that boilerplate).

Make an example in mmgr/README more consistent with surrounding text.

Update an obsolete cross-reference in a comment in storage/block.h.

Zhuo Ql

Discussion: https://postgr.es/m/44296255.1819230.1524889719001@mail.yahoo.com

Add some debug printouts focused on the idea that MapViewOfFileEx might
be rounding its virtual memory allocation up more than we expect (and,
in particular, more than VirtualAllocEx does).

Once we've seen what this reports in one of the failures on buildfarm
members dory or jacana, we might revert this ... or perhaps just
decrease the log level.

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

The core PLs have been extension-ified for seven years now, and we can
reasonably hope that all out-of-core PLs have been too.  So adjust a few
places that were still recommending CREATE LANGUAGE as the user-level
way to install a PL.

Discussion: https://postgr.es/m/CA+TgmoaJTUDMSuSCg4k08Dv8vhbrJq9nP3ZfPbmysVz_616qxw@mail.gmail.com

Newer perltidy versions can just avoid writing backup files, so we don't
need the old dance of deleting them afterwards.  Supported since 20120619.

https://metacpan.org/source/SHANCOCK/Perl-Tidy-20120619/CHANGES#L61