Index-only scans avoid taking a lock on the VM buffer, which would
cause a lot of contention. To be correct, that requires some intricate
assumptions that weren't completely documented in the previous
comment.

Reviewed by Robert Haas.

The main problem is that DocBook SGML allows indexterm elements just
about everywhere, but DocBook XML is stricter.  For example, this common
pattern

    <varlistentry>
     <indexterm>...</indexterm>
     <term>...</term>
     ...
    </varlistentry>

needs to be changed to something like

    <varlistentry>
     <term>...<indexterm>...</indexterm></term>
     ...
    </varlistentry>

See also bb4eefe7.

There is currently nothing in the build system that enforces that things
stay valid, because that requires additional tools and will receive
separate consideration.

Report by Tom Lane

Report by Tom Lane

Allow for translatable string, rather than use "or"

The previous coding would potentially cause attaching to segment A to
fail if segment B was at the same time in the process of going away.

Andres Freund, with a comment tweak by me

Fix for commit 14ea8936

Report by Andres Freund

This includes removing tabs after periods in C comments, which was
applied to back branches, so this change should not effect backpatching.

Report by Noah Misch

Logic is correct, matching handling of LP_DEAD elsewhere.

Report by Amit Langote

Commit d298b50a by Heikki Linnakangas
requested that the version check message be updated at next release, suggesting
that the appropriate text would be “9.3 or later”. The logic used for the check
indicates that the correct text for 9.4 is “9.3 or 9.4”, since the logic would
cause this to fail for later releases.

Found via valgrind. The bug exists since the introduction of the walsender,
so backpatch to 9.0.

Andres Freund

When array of char * was used as target for a FETCH statement returning more
than one row, it tried to store all the result in the first element. Instead it
should dump array of char pointers with right offset, use the address instead
of the value of the C variable while reading the array and treat such variable
as char **, instead of char * for pointer arithmetic.

Patch by Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>

Previously some I/O errors were ignored.

Heikki updated configure.in but evidently forgot to include the updated
configure script in the commit.  Per buildfarm.

Commit fad153ec modified sinval.c to reduce
the number of calls into sinvaladt.c (which require taking a shared lock)
by keeping a local buffer of collected-but-not-yet-processed messages.
However, if processing of the last message in a batch resulted in a
recursive call to ReceiveSharedInvalidMessages, we could overwrite that
message with a new one while the outer invalidation function was still
working on it.  This would be likely to lead to invalidation of the wrong
cache entry, allowing subsequent processing to use stale cache data.
The fix is just to make a local copy of each message while we're processing
it.

Spotted by Andres Freund.  Back-patch to 8.4 where the bug was introduced.

Commit 261c7d4b removed the "m" field
from struct LINE, but neglected to make pg_type.h's idea of the type's
size match.  This resulted in reading past the end of palloc'd LINE
values when inserting them into tuples etc.  In principle that could
cause a SIGSEGV, though the odds of detectable problems seem low.

Bump catversion since this makes an incompatible on-disk format change.
Note that if the line type had been in use in the field, this would
break pg_upgrade'ability of databases containing line values; but
it seems unlikely that there are any (they'd have had to be compiled
with -DENABLE_LINE_TYPE).

Spotted by Andres Freund.

This was accidentally broken in commits cfa1b4a7/5e8e794e.
It saves a line or so to call ftello unconditionally in _CloseArchive,
but we have to expect that it might fail if we're not in hasSeek mode.
Per report from Bernd Helmle.

In passing, improve _getFilePos to print an appropriate message if
ftello fails unexpectedly, rather than just a vague complaint about
"ftell mismatch".

Etsuro Fujita

This is entirely harmless, but still wrong. Noticed by coverity.

Andres Freund

Andres Freund, noticed by coverity.

Silences coverity and is more consistent with other functions in the
same file.

Andres Freund

If they were not 'oldtup.t_data' would be dereferenced while set to NULL
in case of a full page image for block 0.

Do so primarily to silence coverity; but also to make sure this prerequisite
isn't changed without adapting the replay routine as that would appear to
work in many cases.

Andres Freund

It's easy to forget using SYSTEMQUOTEs when constructing command strings
for system() or popen(). Even if we fix all the places missing it now, it is
bound to be forgotten again in the future. Introduce wrapper functions that
do the the extra quoting for you, and get rid of SYSTEMQUOTEs in all the
callers.

We previosly used SYSTEMQUOTEs in all the hard-coded command strings, and
this doesn't change the behavior of those. But user-supplied commands, like
archive_command, restore_command, COPY TO/FROM PROGRAM calls, as well as
pgbench's \shell, will now gain an extra pair of quotes. That is desirable,
but if you have existing scripts or config files that include an extra
pair of quotes, those might need to be adjusted.

Reviewed by Amit Kapila and Tom Lane

ruleutils.c tries to cope with additions/deletions/renamings of columns in
tables referenced by views, by means of adding machine-generated aliases to
the printed form of a view when needed to preserve the original semantics.
A recent blog post by Marko Tiikkaja pointed out a case I'd missed though:
if one input of a join with USING is itself a join, there is nothing to
stop the user from adding a column of the same name as the USING column to
whichever side of the sub-join didn't provide the USING column.  And then
there'll be an error when the view is re-parsed, since now the sub-join
exposes two columns matching the USING specification.  We were catching a
lot of related cases, but not this one, so add some logic to cope with it.

Back-patch to 9.3, which is the first release that makes any serious
attempt to cope with such cases (cf commit 2ffa740b and follow-ons).