someone else has just updated it, we have to set priorXmax to that tuple's
xmax (ie, the XID of the other xact that updated it) before looping back to
examine the next tuple.  Obviously, the next tuple in the update chain should
have that XID as its xmin, not the same xmin as the preceding tuple that we
had been trying to lock.  The mismatch would cause the EvalPlanQual logic to
decide that the tuple chain ended in a deletion, when actually there was a
live tuple that should have been found.

I inserted this error when recently adding logic to EvalPlanQual to make it
lock tuples before returning them (as opposed to the old method in which the
lock would occur much later, causing a great deal of work to be wasted if we
only then discover someone else updated it).  Sigh.  Per today's report from
Takahiro Itagaki of inconsistent results during pgbench runs.

This uses the same infrastructure with EXPLAIN BUFFERS to support
{shared|local}_blks_{hit|read|written} andtemp_blks_{read|written}
columns in the pg_stat_statements view. The dumped file format
also updated.

Thanks to Robert Haas for the review.

as required by SQL standard.

of the string".  The previous coding treated only -1 that way, and would
produce an invalid result value for other negative values.

We ought to fix it so that 2-parameter bit substring() is a different C
function and the 3-parameter form throws error for negative length, but
that takes a pg_proc change which is impractical in the back branches;
and in any case somebody might be relying on -1 working this way.
So just do this as a back-patchable fix.

It is absolutely not okay to throw an ereport(ERROR) in any random place in
the code just because DoingCommandRead is set; interrupting, say, OpenSSL
in the midst of its activities is guaranteed to result in heartache.

Instead of that, undo the original optimizations that threw away
QueryCancelPending anytime we were starting or finishing a command read, and
instead discard the cancel request within ProcessInterrupts if we find that
there is no HS reason for forcing a cancel and we are DoingCommandRead.

In passing, may I once again condemn the practice of changing the code
and not fixing the adjacent comment that you just turned into a lie?

we're not going to support that anymore.

I did keep the 64-bit-CRC-with-32-bit-arithmetic code, since it has a
performance excuse to live.  It's a bit moot since that's all ifdef'd
out, of course.

Add missing varlena header to TableSpaceOpts structure.  And, per
Tom Lane, instead of calling tablespace_reloptions in CacheMemoryContext,
call it in the caller's memory context and copy the value over
afterwards, to reduce the chances of a session-lifetime memory leak.

versions < 5.8.  Also, if there's no Perl, emit a warning informing the
user that he won't be able to build from a CVS pull.  This is exactly the
same treatment we give Bison and Perl, and for the same reasons.

provide a working 64-bit integer datatype.  As recently noted, we've been
broken on such platforms since early in the 8.4 development cycle.  Since
it took nearly two years for anyone to even notice, it seems that the
rationale for continuing to support such platforms has reached the point
of non-existence.  Rather than thrashing around to try to make it work
again, we'll just admit up front that this no longer works.

Back-patch to 8.4 since that branch is also broken.

We should go around to remove INT64_IS_BUSTED support, but just in HEAD,
so that seems like material for a separate commit.

For simplicity, use PG_MAJORVERSION rather than PG_VERSION for creation
of the PG_VERSION file.

access, per testing with CLOBBER_CACHE_ALWAYS.  Minor other editorialization.

Per Stefan.

overridden in the snapshot build script.  $MAJORVERSION is what it really
wanted anyway, so we can tighten up the parsing of --set-version's argument.

Silences complaints from "make man", and allows these man pages
to be included in man3/.

--only-analyze mode is for _vacuumdb_, not pg_dump.

OS specific with some distinguishing between signaling and quiet nans. It's not
really importnat for us here anyway.

is not necessary needed, but some compilers complain about it.

superfluous include files.

VACUUM FULL was renamed to VACUUM FULL INPLACE. Also added a new
option -i, --inplace for vacuumdb to perform FULL INPLACE vacuuming.

Since the new VACUUM FULL uses CLUSTER infrastructure, we cannot
use it for system tables. VACUUM FULL for system tables always
fall back into VACUUM FULL INPLACE silently.

Itagaki Takahiro, reviewed by Jeff Davis and Simon Riggs.

Preserve relfilenodes for views and composite types --- even though we
don't store data in, them, they do consume relfilenodes.

Bump catalog version.

with PG version 8.2-8.4.

identify the new API.

Add support to pg_dump --binary-upgrade to preserve all relfilenodes,
for use by pg_migrator.

Implement pg_dump --only-analyze for use by pg_migrator to only analyze
all databases.

Move OIDCHARS to proper include file.

Use OIDCHARS for oid character length, rather than '10', in tablespace
code.