backend-private struct

Remove previous timeline ID from checkpoint.

Since recovery now always ends with an end-of-recovery record rather
than a checkpoint, a checkpoint never causes a timeline switch.
Therefore, it doesn't need to store a previous timeline ID and a
current timeline ID any more.

Note that this affects the signature of the SQL-callable function
pg_control_checkpoint().

Remove the end-of-recovery checkpoint in all cases.

For many years, we've been issuing a special end-of-recovery WAL
record rather than performing an end-of-recovery checkpoint when a
standby is promoted.  This has the advantage of speeding up promotion.
However, it's advantageous to do this at the end of crash recovery as
well, and for the same reasons.  Plus, it's actually simpler this way,
because having only one way to do something rather than two means we
need less code.

We now always request a checkpoint at the end of recovery. If we
crash again before that checkpoint completes, recovery will begin
from the previous checkpoint that we performed - or replayed. This
behavior is not new as far as archive recovery is concerned, but now
it can also happen for crash recovery.

At initdb time, we now initialize the nextXid counter to 4 rather
than to 3. The code for logging standby shapshots and handling them
on th standby can't handle 3, because we set latestCompleteXid =
nextXid - 1, and 2 is not a normal XID. This is arguably a preexisting
bug, but because we didn't log a standby snapshot when starting from
an end-of-recovery checkpoint, we happened not to ever hit the
problematic case.

Fix aggregate logging of pgbench.

Remove meaningless "failures" column from the aggregate logging. It
was just a sum of "serialization failures" and "deadlock failures".
Pointed out by Tom Lane. Patch reviewed by Fabien COELHO.

Discussion: https://postgr.es/m/4183048.1649536705%40sss.pgh.pa.us

Fix the check to limit sync workers.

We don't allow to invoke more sync workers once we have reached the sync
worker limit per subscription. But the check to enforce this also doesn't
allow to launch an apply worker if it gets restarted.

This code was introduced by commit de43897122 but we caught the problem
only with the test added by recent commit c91f71b9dc which started failing
occasionally in the buildfarm.

As per buildfarm.
Diagnosed-by: Amit Kapila, Masahiko Sawada, Tomas Vondra
Author: Amit Kapila
Backpatch-through: 10
Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com
    https://postgr.es/m/f90d2b03-4462-ce95-a524-d91464e797c8@enterprisedb.com

Add missing error handling in pg_md5_hash().

It failed to provide an error string as expected for the
admittedly-unlikely case of OOM in pg_cryptohash_create().
Also, make it initialize *errstr to NULL for success,
as pg_md5_binary() does.

Also add missing comments.  Readers should not have to
reverse-engineer the API spec for a publicly visible routine.

Avoid invalid array reference in transformAlterTableStmt().

Don't try to look at the attidentity field of system attributes,
because they're not there in the TupleDescAttr array.  Sometimes
this is harmless because we accidentally pick up a zero, but
otherwise we'll report "no owned sequence found" from an attempt
to alter a system attribute.  (It seems possible that a SIGSEGV
could occur, too, though I've not seen it in testing.)

It's not in this function's charter to complain that you can't
alter a system column, so instead just hard-wire an assumption
that system attributes aren't identities.  I didn't bother with
a regression test because the appearance of the bug is very
erratic.

Per bug #17465 from Roman Zharkov.  Back-patch to all supported
branches.  (There's not actually a live bug before v12, because
before that get_attidentity() did the right thing anyway.
But for consistency I changed the test in the older branches too.)

Discussion: https://postgr.es/m/17465-f2a554a6cb5740d3@postgresql.org

Fix second race condition in 002_archiving.pl with archive_cleanup_command

Checking the execution of archive_cleanup_command on a standby requires
a valid checkpoint coming from its primary, but the logic did not check
that the standby replayed up to the point of the checkpoint, causing the
test checking for the execution of archive_cleanup_command to fail.
This race was more visible in slow environments.

Issue introduced in 46dea24, so no backpatch is needed.

Author: Tom Lane
Discussion: https://postgr.es/m/4015413.1649454951@sss.pgh.pa.us

Add additional documentation for row filters.

Commit 52e4f0cd47 added a feature to allow specifying row filters for
logical replication of tables. This patch adds detailed documentation on
that feature including examples to make it easier for users to understand.

Author: Peter Smith, Euler Taveira
Reviewed By: Greg Nancarrow, Aleksander Alekseev, Amit Kapila, Ajin Cherian, Alvaro Herrera
Discussion: https://postgr.es/m/CAHut+PtnsBr59=_NvxXp_=S-em0WxyuDOQmSTuHGb4sVhkHffg@mail.gmail.com

Fix race in TAP test 002_archiving.pl when restoring history file

This test, introduced in df86e52, uses a second standby to check that
it is able to remove correctly RECOVERYHISTORY and RECOVERYXLOG at the
end of recovery.  This standby uses the archives of the primary to
restore its contents, with some of the archive's contents coming from
the first standby previously promoted.  In slow environments, it was
possible that the test did not check what it should, as the history file
generated by the promotion of the first standby may not be stored yet on
the archives the second standby feeds on.  So, it could be possible that
the second standby selects an incorrect timeline, without restoring a
history file at all.

This commits adds a wait phase to make sure that the history file
required by the second standby is archived before this cluster is
created.  This relies on poll_query_until() with pg_stat_file() and an
absolute path, something not supported in REL_10_STABLE.

While on it, this adds a new test to check that the history file has
been restored by looking at the logs of the second standby.  This
ensures that a RECOVERYHISTORY, whose removal needs to be checked,
is created in the first place.  This should make the test more robust.

This test has been introduced by df86e52, but it came in light as an
effect of the bug fixed by acf1dd42, where the extra restore_command
calls made the test much slower.

Reported-by: Andres Freund
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 11

Handle compression level in pg_receivewal for LZ4

The new option set of pg_receivewal introduced in 042a923 to control the
compression method makes it now easy to pass down various options,
including the compression level.  The change to be able to do is simple,
and requires one LZ4F_preferences_t fed to LZ4F_compressBegin().

Note that LZ4F_INIT_PREFERENCES could be used to initialize the contents
of LZ4F_preferences_t as required by LZ4, but this is only available
since v1.8.3.  memset()'ing its structure to 0 is enough.

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

Add a temp-install prerequisite to src/interfaces/ecpg "checktcp".

The target failed, tested $PATH binaries, or tested a stale temporary
installation.  Commit c66b438db62748000700c9b90b585e756dd54141 missed
this.  Back-patch to v10 (all supported versions).

Don't retry restore_command while reading ahead.

Suppress further attempts to read ahead in the WAL if we run out of
data, until the records already decoded have been replayed.  This
restores the traditional behavior for continuous archive recovery, which
is to retry the failing restore_command only every 5 seconds.  With the
coding in 5dc0418f, we would start retrying every time through the
recovery loop when our WAL decoding window hit the end of the current
segment and we tried to look ahead into a not-yet-available next file.
That was very slow.

Also change the no_readahead_until mechanism to use <= rather than <,
which seems more useful.  Otherwise we'd either get one extra unwanted
retry of restore_command, or we'd need to add 1 to an LSN.

No change in behavior for regular streaming.  That was already limited
by the flushedUpto variable, which won't be updated until we replay what
we have already.

Reported by Andres Freund while analyzing the failure of a TAP test on
build farm animal skink (investigation ongoing but probably due to
otherwise unrelated timing bugs triggered by this slowness magnified by
valgrind).

Discussion: https://postgr.es/m/20220409005910.alw46xqmmgny2sgr%40alap3.anarazel.de

pgstat: Use correct lock level in pgstat_drop_all_entries().

Previously we didn't, which lead to an assertion failure when resetting
partially loaded statistics. This was encountered on the buildfarm, for
as-of-yet unknown reasons.

Ttighten up a validity check when reading the stats file, verifying 'E'
signals the end of the file (rather than just stopping reading). That's then
used in a test appending to the stats file that crashed before the fix in
pgstat_drop_all_entries().

Reported by buildfarm animals mylodon and kestrel, via Tom Lane.

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

Fix incorrect logic in HaveRegisteredOrActiveSnapshot().

This function gave the wrong answer when there's more than one
RegisteredSnapshots entry, whether or not any of them is the
CatalogSnapshot.  This leads to assertion failure in some scenarios
involving fetching toasted data using a cursor.  (As per discussion,
I'm dubious that this is the right contract to be enforcing at all;
but it surely doesn't help to be enforcing it incorrectly.)

Fetching toasted data using a cursor is evidently under-tested,
so add a test case too.

Per report from Erik Rijkers.  This is new code, so no need for
back-patch.

Discussion: https://postgr.es/m/dc9dd229-ed30-6c62-4c41-d733ffff776b@xs4all.nl

Build libpq test programs under MSVC

This allows the newly added TAP tests to run.

Fix some trailing whitespace in documentation files

Use standard timeout, in 010_pg_basebackup.pl.

Per buildfarm member mandrill.  The test is new in v15, so no back-patch.

Fix multi-table VACUUM VERBOSE accounting.

Per-backend global variables like VacuumPageHit are initialized once per
VACUUM command.  This was missed by commit 49c9d9fc, which unified
VACUUM VERBOSE and autovacuum logging.  As a result of that oversight,
incorrect values were shown when multiple relations were processed by a
single VACUUM VERBOSE command.

Relations that happened to be processed later on would show "buffer
usage:" values that incorrectly included buffer accesses made while
processing earlier unrelated relations.  The same accesses were counted
multiple times.

To fix, take initial values for the tracker variables at the start of
heap_vacuum_rel(), and report delta values later on.

psql: fix \l display for pre-v15 databases.

With a pre-v15 server, show NULL for the "ICU Locale" column,
matching what you see in v15 when the database locale isn't ICU.
The previous coding incorrectly repeated datcollate here.

(There's an unfinished discussion about whether to consolidate
these columns in \l output, but in any case we'd want this fix
for \l+ output.)

Euler Taveira, per report from Christoph Berg

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

Tighten ComputeXidHorizons' handling of walsenders.

ComputeXidHorizons (nee GetOldestXmin) thought that it could identify
walsenders by checking for proc->databaseId == 0.  Perhaps that was
safe when the code was written, but it's been wrong at least since
autovacuum was invented.  Background processes that aren't connected
to any particular database, such as the autovacuum launcher and
logical replication launcher, look like that too.

This imprecision is harmful because when such a process advertises an
xmin, the result is to hold back dead-tuple cleanup in all databases,
though it'd be sufficient to hold it back in shared catalogs (which
are the only relations such a process can access).  Aside from being
generally inefficient, this has recently been seen to cause regression
test failures in the buildfarm, as a consequence of the logical
replication launcher's startup transaction preventing VACUUM from
marking pages of a user table as all-visible.

We only want that global hold-back effect for the case where a
walsender is advertising a hot standby feedback xmin.  Therefore,
invent a new PGPROC flag that says that a process' xmin should be
considered globally, and check that instead of using the incorrect
databaseId == 0 test.  Currently only a walsender sets that flag,
and only if it is not connected to any particular database.  (This is
for bug-compatibility with the undocumented behavior of the existing
code, namely that feedback sent by a client who has connected to a
particular database would not be applied globally.  I'm not sure this
is a great definition; however, such a client is capable of issuing
plain SQL commands, and I don't think we want xmins advertised for
such commands to be applied globally.  Perhaps this could do with
refinement later.)

While at it, I rewrote the comment in ComputeXidHorizons, and
re-ordered the commented-upon if-tests, to make them match up
for intelligibility's sake.

This is arguably a back-patchable bug fix, but given the lack of
complaints I think it prudent to let it age awhile in HEAD first.

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

VACUUM VERBOSE: Show dead items for an empty table.

Be consistent about the lines that VACUUM VERBOSE outputs by including
an "index scan not needed: " line for completely empty tables. This
makes the output more readable, especially with multiple distinct VACUUM
operations processed by the same VACUUM command.  It's also more
consistent; even empty tables can use the failsafe, which wasn't
reported in the standard way until now.

Follow-up to commit 6e20f460, which taught VACUUM VERBOSE to be more
consistent about reporting on scanned pages with empty tables.

Adjust VACUUM's removable cutoff log message.

The age of OldestXmin (a.k.a. "removable cutoff") when VACUUM ends often
indicates the approximate number of XIDs consumed while VACUUM ran.
However, there is at least one important exception: the cutoff could be
held back by a snapshot that was acquired before our VACUUM even began.
Successive VACUUM operations may even use exactly the same old cutoff in
extreme cases involving long held snapshots.

The log messages that described how removable cutoff aged (which were
added by commit 872770fd) created the impression that we were reporting
on how VACUUM's usable cutoff advanced while VACUUM ran, which was
misleading in these extreme cases.  Fix by using a more general wording.

Per gripe from Tom Lane.

In passing, relocate related instrumentation code for clarity.

Author: Peter Geoghegan <[email protected]>
Discussion: https://postgr.es/m/1643035.1650035653@sss.pgh.pa.us

Revert "Temporarily add some probes of tenk1's relallvisible in create_index.sql."

This reverts commit 5bb2b6abc8d6cf120a814317816e4384bcbb9c1e.
Not needed anymore.

Small cleanups in SQL/JSON code

These are to keep Coverity happy. In one case remove a redundant NULL
check, and in another explicitly ignore a function result that is already
known.

pgstat: set timestamps of fixed-numbered stats after a crash.

When not loading stats at startup (i.e. pgstat_discard_stats() getting
called), reset timestamps of fixed numbered stats would be left at
0. Oversight in 5891c7a8ed8.

Instead use pgstat_reset_after_failure() and add tests verifying that
fixed-numbered reset timestamps are set appropriately.

Reported-By: "David G. Johnston" <[email protected]>
Discussion: https://postgr.es/m/CAKFQuwamFuaQHKdhcMt4Gbw5+Hca2UE741B8gOOXoA=TtAd2Yw@mail.gmail.com

Have CLUSTER ignore partitions not owned by caller

If a partitioned table has partitions owned by roles other than the
owner of the partitioned table, don't include them in the to-be-
clustered list.  This is similar to what VACUUM FULL does (except we do
it sooner, because there is no reason to postpone it).  Add a simple
test to verify that only owned partitions are clustered.

While at it, change memory context switch-and-back to occur once per
partition instead of outside of the loop.

Author: Justin Pryzby <[email protected]>
Reviewed-by: Zhihong Yu <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>
Discussion: https://postgr.es/m/20220411140609[email protected]

Reword text on ROW SHARE lock as acquired by SELECT FOR <lock>

It was missing lock levels FOR KEY SHARE and FOR NO KEY EXCLUSIVE; but
also SELECT FOR UPDATE is not a command separate from SELECT, as the
original text implied.  It is clearer to state that FOR <lock strength>
is an option of regular SELECT.

Per suggestion from Joey Bodoia <[email protected]>

Reviewed-by: Joey Bodoia <[email protected]> (offlist)
Reviewed-by: Erikjan Rijkers <[email protected]>
Discussion: https://postgr.es/m/164908765512.682.17348032020747341013@wrigleys.postgresql.org

Temporarily add some probes of tenk1's relallvisible in create_index.sql.

This is to gather some more evidence about why buildfarm member wrasse
is failing.  We should revert it (or at least scale it way back) once
that's resolved.

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

Improve a couple of sql/json error messages

Fix the grammar in two, and add a hint to one.

Fix transformJsonBehavior

Commit 1a36bc9dba8 conained some logic that was a little opaque and
could have involved a NULL dereference, as complained about by Coverity.
Make the logic more transparent and in doing so avoid the NULL
dereference.

pageinspect: Fix handling of all-zero pages

Getting from get_raw_page() an all-zero page is considered as a valid
case by the buffer manager and it can happen for example when finding a
corrupted page with zero_damaged_pages enabled (using zero_damaged_pages
to look at corrupted pages happens), or after a crash when a relation
file is extended before any WAL for its new data is generated (before a
vacuum or autovacuum job comes in to do some cleanup).

However, all the functions of pageinspect, as of the index AMs (except
hash that has its own idea of new pages), heap, the FSM or the page
header have never worked with all-zero pages, causing various crashes
when going through the page internals.

This commit changes all the pageinspect functions to be compliant with
all-zero pages, where the choice is made to return NULL or no rows for
SRFs when finding a new page.  get_raw_page() still works the same way,
returning a batch of zeros in the bytea of the page retrieved.  A hard
error could be used but NULL, while more invasive, is useful when
scanning relation files in full to get a batch of results for a single
relation in one query.  Tests are added for all the code paths
impacted.

Reported-by: Daria Lepikhova
Author: Michael Paquier
Discussion: https://postgr.es/m/561e187b-3549-c8d5-03f5-525c14e65bd0@postgrespro.ru
Backpatch-through: 10

Add missing spaces after single-line comments

Only 1 of 3 of these changes appear to be handled by pgindent. That change
is new to v15.  The remaining two appear to be left alone by pgindent. The
exact reason for that is not 100% clear to me.  It seems related to the
fact that it's a line that contains *only* a single line comment and no
actual code.  It does not seem worth investigating this in too much
detail.  In any case, these do not conform to our usual practices, so fix
them.

Author: Justin Pryzby
Discussion: https://postgr.es/m/20220411020336[email protected]

Docs: fix some spelling mistakes and also do some wordsmithing

All except one of these are new to v15.  Only one of the wordsmithing
changes appears in older versions. The wordsmithing improvement does not
seem significant enough to warrant backpatching.

Author: Justin Pryzby
Discussion: https://postgr.es/m/20220411020336[email protected]

Fix case sensitivity in psql's tab completion for GUC names.

Input for these should be case-insensitive, but was not completely
so.  Comparing to the similar queries for timezone names, I realized
that we'd missed forcing the comparison pattern to lower-case.
With that, it behaves as I expect.

While here, flatten the sub-selects in these queries; I don't
find that those add any readability.

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

Further tweak the default behavior of psql's \dconfig.

Define "parameters with non-default settings" as being those that
not only have pg_settings.source different from 'default', but
also have a current value different from the hard-wired boot_val.
Adding the latter restriction removes a number of not-very-interesting
cases where the active setting is chosen by initdb but in practice
tends to be the same all the time.

Per discussion with Jonathan Katz.

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

Prevent access to no-longer-pinned buffer in heapam_tuple_lock().

heap_fetch() used to have a "keep_buf" parameter that told it to return
ownership of the buffer pin to the caller after finding that the
requested tuple TID exists but is invisible to the specified snapshot.
This was thoughtlessly removed in commit 5db6df0c0, which broke
heapam_tuple_lock() (formerly EvalPlanQualFetch) because that function
needs to do more accesses to the tuple even if it's invisible.  The net
effect is that we would continue to touch the page for a microsecond or
two after releasing pin on the buffer.  Usually no harm would result;
but if a different session decided to defragment the page concurrently,
we could see garbage data and mistakenly conclude that there's no newer
tuple version to chain up to.  (It's hard to say whether this has
happened in the field.  The bug was actually found thanks to a later
change that allowed valgrind to detect accesses to non-pinned buffers.)

The most reasonable way to fix this is to reintroduce keep_buf,
although I made it behave slightly differently: buffer ownership
is passed back only if there is a valid tuple at the requested TID.
In HEAD, we can just add the parameter back to heap_fetch().
To avoid an API break in the back branches, introduce an additional
function heap_fetch_extended() in those branches.

In HEAD there is an additional, less obvious API change: tuple->t_data
will be set to NULL in all cases where buffer ownership is not returned,
in particular when the tuple exists but fails the time qual (and
!keep_buf).  This is to defend against any other callers attempting to
access non-pinned buffers.  We concluded that making that change in back
branches would be more likely to introduce problems than cure any.

In passing, remove a comment about heap_fetch that was obsoleted by
9a8ee1dc6.

Per bug #17462 from Daniil Anisimov.  Back-patch to v12 where the bug
was introduced.

Discussion: https://postgr.es/m/17462-9c98a0f00df9bd36@postgresql.org

Remove extraneous blank lines before block-closing braces

These are useless and distracting.  We wouldn't have written the code
with them to begin with, so there's no reason to keep them.

Author: Justin Pryzby <[email protected]>
Discussion: https://postgr.es/m/20220411020336[email protected]
Discussion: https://postgr.es/m/attachment/133167/0016-Extraneous-blank-lines.patch

Release cache tuple when no longer needed

There was a small buglet in commit 52e4f0cd472d whereby a tuple acquired
from cache was not released, giving rise to WARNING messages; fix that.

While at it, restructure the code a bit on stylistic grounds.

Author: Hou zj <[email protected]>
Reported-by: Peter Smith <[email protected]>
Reviewed-by: Amit Kapila <[email protected]>
Discussion: https://postgr.es/m/CAHut+PvKTyhTBtYCQsP6Ph7=o-oWRSX+v+PXXLXp81-o2bazig@mail.gmail.com

Fix finalization for json_objectagg and friends

Commit f4fb45d15c misguidedly tried to free some state during aggregate
finalization for json_objectagg. This resulted in attempts to access
freed memory, especially when the function is used as a window function.
Commit 4eb9798879 attempted to ameliorate that, but in fact it should
just be ripped out, which is done here. Also add some regression tests
for json_objectagg in various flavors as a window function.

Original report from Jaime Casanova, diagnosis by Andres Freund.

Discussion: https://postgr.es/m/YkfeMNYRCGhySKyg@ahch-to

Fix incorrect format placeholders

Docs: wording improvement for compute_query_id = regress

It's more accurate to say that the query identifier is not shown when
compute_query_id = regress rather than to say it is hidden.

This change (ebf6c5249) appeared in v14, so it makes sense to backpatch
this small adjustment to keep the documents consistent between v14 and
master.

Author: Justin Pryzby
Discussion: https://postgr.es/m/20220411020336[email protected]
Backpatch-through: 14, where compute_query_id = regress was added

Remove "recheck" argument from check_index_is_clusterable()

The last usage of this argument in this routine can be tracked down to
7e2f9062, aka 11 years ago.  Getting rid of this argument can also be an
advantage for extensions calling check_index_is_clusterable(), as it
removes any need to worry about the meaning of what a recheck would be
at this level.

Author: Justin Pryzby
Discussion: https://postgr.es/m/20220411140609[email protected]

Docs: tidy up various usages of the productname tag

This tries to bring a bit more consistency to the use of the <productname>
tag in the documents.  This fixes a couple of mistakes with our own
product.  We definitely should be consistently calling that PostgreSQL
when we're referring to the modern-day version of the software.

This also tidies up a couple of inconsistencies with the case of other
product names, namely Emacs and Python.  We also get rid of some incorrect
usages of <productname> and replace them with <literal>.

Many of these mistakes exist in the back branches, but they don't quite
seem critical enough to warrant fixing them in prior versions at this
stage.

Author: Justin Pryzby
Discussion: https://postgr.es/m/20220411020336[email protected]

Rework compression options of pg_receivewal

Since babbbb5 and the introduction of LZ4 in pg_receivewal, the
compression of the WAL archived is controlled by two options:
- --compression-method with "gzip", "none" or "lz4" as possible value.
- --compress=N to specify a compression level.  This includes a
backward-incompatible change where a value of 0 leads to a failure
instead of no compression enforced.

This commit takes advantage of a4b5754 and 3603f7c to rework the
compression options of pg_receivewal, as of:
- The removal of --compression-method.
- The extenction of --compress to use the same grammar as pg_basebackup,
with a METHOD:DETAIL format, where a METHOD is "gzip", "none" or "lz4"
and a DETAIL is a comma-separated list of options, the only keyword
supported is now "level" to control the compression level.  If only an
integer is specified as value of this option, "none" is implied on 0
and "gzip" is implied otherwise.  This brings back --compress to be
backward-compatible with ~14, while still supporting LZ4.

This has also the advantage of centralizing the set of checks used by
pg_receivewal to validate its compression options.

Author: Michael Paquier
Reviewed-by: Robert Haas, Georgios Kokolatos
Discussion: https://postgr.es/m/[email protected]

Docs: adjust wording about basebackup_to_shell's required_role GUC

Author: Justin Pryzby
Reviewed-by: Robert Haas
Discussion: https://postgr.es/m/20220411020336[email protected]

Docs: adjust pg_upgrade syntax to mark -B as optional

This was made optional in 959f6d6a1.

Author: Justin Pryzby
Discussion: https://postgr.es/m/20220411020336[email protected]
Backpatch-through: 13, where -B was made optional

Doc: tweak textsearch.sgml for SEO purposes.

Google seems to like to return textsearch.html for queries about
GIN and GiST indexes, even though it's not a primary reference
for either.  It seems likely that that's because those keywords
appear in the page title.  Since "GIN and GiST Index Types" is
not a very apposite title for this material anyway, rename the
section in hopes of stopping that.

Also provide explicit links to the GIN and GiST chapters, to help
anyone who finds their way to this page regardless.

Per gripe from Jan Piotrowski.  Back-patch to supported branches.
(Unfortunately Google is likely to continue returning the 9.1
version of this page, but improving that situation is a matter
for the www team.)

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

Docs: avoid confusing use of the word "synchronized"

It's misleading to call the data directory the "synchronized data
directory" when discussing a crash scenario when using pg_rewind's
--no-sync option.  Here we just remove the word "synchronized" to avoid
any possible confusion.

Author: Justin Pryzby
Discussion: https://postgr.es/m/20220411020336[email protected]
Backpatch-through: 12, where --no-sync was added

Revert the addition of GetMaxBackends() and related stuff.

This reverts commits 0147fc7, 4567596, aa64f23, and 5ecd018.
There is no longer agreement that introducing this function
was the right way to address the problem. The consensus now
seems to favor trying to make a correct value for MaxBackends
available to mdules executing their _PG_init() functions.

Nathan Bossart

Discussion: http://postgr.es/m/20220323045229.i23skfscdbvrsuxa@jrouhaud

Remove not-very-useful early checks of __pg_log_level in logging.h.

Enforce __pg_log_level message filtering centrally in logging.c,
instead of relying on the calling macros to do it.  This is more
reliable (e.g. it works correctly for direct calls to pg_log_generic)
and it saves a percent or so of total code size because we get rid of
so many duplicate checks of __pg_log_level.

This does mean that argument expressions in a logging macro will be
evaluated even if we end up not printing anything.  That seems of
little concern for INFO and higher levels as those messages are printed
by default, and most of our frontend programs don't even offer a way to
turn them off.  I left the unlikely() checks in place for DEBUG
messages, though.

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

Doc: update description of random() function.

Commit 3804539e4 neglected to update the documentation's claim that
random() uses a "linear congruential algorithm".  In hopes of avoiding
the same mistake if someone replaces our PRNG again, just say it's a
deterministic pseudo-random number generator and leave it at that.
Anybody who really wants to know can look in the source code.

COMPATIBILITY NOTE FOR RELEASE NOTES: 3804539e4's commit message
really should have mentioned that the random() sequence after
setseed(), while still repeatable, will differ from what you got
in pre-v15 releases.

Noted by Dagfinn Ilmari Mannsåker; wording suggestion by Dean Rasheed.

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

Use WRITE_ENUM_FIELD for enum field

Make node output prefix match node structure name

as done in e58136069687b9cf29c27281e227ac397d72141d

adjust_partition_colnos mustn't be called if not needed

Add an assert to make this very explicit, as well as a code comment.
The former should silence Coverity complaining about this.

Introduced by 7103ebb7aae8.

Reported-by: Ranier Vilela
Discussion: https://postgr.es/m/CAEudQAqTTAOzXiYybab+1DQOb3ZUuK99=p_KD+yrRFhcDbd0jg@mail.gmail.com

Fix documentation for pg_stat_recovery_prefetch.

The table was in the wrong section and using an older type of link, as
reported by Sirisha, and also using an older table layout, as I noticed
while trying to figure out how and when it might have got out of sync.

Defect in commit 5dc0418f.

Author: sirisha chamarthi <[email protected]>
Author: Thomas Munro <[email protected]>
Discussion: https://postgr.es/m/CAKrAKeVk-LRHMdyT6x_p33eF6dCorM2jed5h_eHdRdv0reSYTA@mail.gmail.com

Fix grammatical errors and typos in logical replication docs.

Author: Justin Pryzby
Reviewed By: Masahiko Sawada
Discussion: https://postgr.es/m/20220411020336[email protected]

Remove WalCompressionMethod in favor of pg_compress_algorithm

The same structure, with the same set of elements (for none, lz4, gzip
and zstd), exists in compression.h, so let's make use of the centralized
version instead of duplicating things.  Some of the variables used
previously for WalCompressionMethod are renamed to stick better with the
new structure and routine names.

WalCompressionMethod was leading to some confusion in walmethods.c, as
it was sometimes used to refer to some data unrelated to WAL.

Reported-by: Robert Haas
Author: Michael Paquier
Reviewed-by: Robert Haas, Georgios Kokolatos
Discussion: https://postgr.es/m/[email protected]

Change mechanism to set up source targetlist in MERGE

We were setting MERGE source subplan's targetlist by expanding the
individual attributes of the source relation completely, early in the
parse analysis phase.  This failed to work when the condition of an
action included a whole-row reference, causing setrefs.c to error out
with
  ERROR:  variable not found in subplan target lists
because at that point there is nothing to resolve the whole-row
reference with.  We can fix this by having preprocess_targetlist expand
the source targetlist for Vars required from the source rel by all
actions.  Moreover, by using this expansion mechanism we can do away
with the targetlist expansion in transformMergeStmt, which is good
because then we no longer pull in columns that aren't needed for
anything.

Add a test case for the problem.

While at it, remove some redundant code in preprocess_targetlist():
MERGE was doing separately what is already being done for UPDATE/DELETE,
so we can just rely on the latter and remove the former.  (The handling
of inherited rels was different for MERGE, but that was a no-longer-
necessary hack.)

Fix outdated, related comments for fix_join_expr also.

Author: Richard Guo <[email protected]>
Author: Álvaro Herrera <[email protected]>
Reported-by: Joe Wildish <[email protected]>
Discussion: https://postgr.es/m/fab3b90a-914d-46a9-beb0-df011ee39ee5@www.fastmail.com

Rename backup_compression.{c,h} to compression.{c,h}

Compression option handling (level, algorithm or even workers) can be
used across several parts of the system and not only base backups.
Structures, objects and routines are renamed in consequence, to remove
the concept of base backups from this part of the code making this
change straight-forward.

pg_receivewal, that has gained support for LZ4 since babbbb5, will make
use of this infrastructure for its set of compression options, bringing
more consistency with pg_basebackup.  This cleanup needs to be done
before releasing a beta of 15.  pg_dump is a potential future target, as
well, and adding more compression options to it may happen in 16~.

Author: Michael Paquier
Reviewed-by: Robert Haas, Georgios Kokolatos
Discussion: https://postgr.es/m/[email protected]

Make XLogRecGetBlockTag() throw error if there's no such block.

All but a few existing callers assume without checking that this
function succeeds.  While it probably will, that's a poor excuse for
not checking.  Let's make it return void and instead throw an error
if it doesn't find the block reference.  Callers that actually need
to handle the no-such-block case must now use the underlying function
XLogRecGetBlockTagExtended.

In addition to being a bit less error-prone, this should also serve
to suppress some Coverity complaints about XLogRecGetBlockRefInfo.

While at it, clean up some inconsistency about use of the
XLogRecHasBlockRef macro: make XLogRecGetBlockTagExtended use
that instead of open-coding the same condition, and avoid calling
XLogRecHasBlockRef twice in relevant code paths.  (That is,
calling XLogRecHasBlockRef followed by XLogRecGetBlockTag is now
deprecated: use XLogRecGetBlockTagExtended instead.)

Patch HEAD only; this doesn't seem to have enough value to consider
a back-branch API break.

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

Remove comment about historic heap vacuuming issue.

Remove comment block about how heap page vacuuming used to set tuples
with storage to LP_UNUSED in a rare edge case that can no longer happen
following commit 8523492d4e.  The comments seem unnecessary now, since
it's now generally clear that heap vacuuming only applies to LP_DEAD
items from VACUUM's first heap pass following more recent work from
commits 12b5ade902 and 4f8d9d1217.

Remove dead code in do_pg_backup_start().

As of commit 39969e2a1, no caller of do_pg_backup_start() passes NULL
for labelfile or tblspcmapfile, nor is it plausible that any would
do so in the future.  Remove the code that coped with that case,
as (a) it's dead and (b) it causes Coverity to bleat about possibly
leaked storage.

While here, do some janitorial work on the function's header comment.

Tweak the default behavior of psql's \dconfig.

\dconfig without an argument originally printed all parameters,
but it seems more useful to print only those parameters with
non-default settings.  You can easily get the show-everything
behavior with "\dconfig *", but that output is unwieldy and
seems unlikely to be wanted very often.

Per suggestion from Christoph Berg.

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

Explicitly ignore guaranteed-true result from pgstat_lock_entry().

With nowait passed as false, pgstat_lock_entry() must return true
so there's no need to check its result.  Coverity seems unconvinced
of this, so whack it upside the head with a (void) cast.

fgetc() returns int, not char.

This has no practical effect, since this code doesn't actually need to
distinguish EOF (-1) from \0377; but it silences a Coverity complaint.

Doc build fix: remove tab from filelist.sgml.

Author: Amit Kapila
Discussion: https://postgr.es/m/CAA4eK1K6z=gu-jppU1dtsyr2BC-pzrq3TYe=RfY+w386dfdiFA@mail.gmail.com

Improve readability of SQL/JSON documentation.

Per review from Justin Pryzby.

Discussion: https://postgr.es/m/f50aca87-6b35-a1b0-2286-f815a589dd83@dunslane.net

Add color support for new frontend detail/hint messages

As before, the defaults are similar to gcc's default appearance.

Avoid re-writing files unnecessarily in src/tools/copyright.pl.

The existing coding resulted in touching every copyright-containing
file in the tree, even if it was already up to date.  That doesn't
matter much for the annual run, but it's an annoyance if you try
to use the script for mop-up at the close of a devel cycle, as
I just did.

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

docs: Note the recovery_min_apply_delay bloats pg_wal.

Those WAL files that we're waiting to apply have to be stored
somewhere.

Thom Brown

Discussion: http://postgr.es/m/CAA-aLv4SkJRK6GGcd0Axt8kt6_eWMEbtG7f8NJpFh+rNshtdNA@mail.gmail.com

Docs: Mention that relpersistence is for sequences now too

Per 344d62fb9.

Author: Justin Pryzby
Discussion: https://postgr.es/m/20220411020336[email protected]

Fix various typos and spelling mistakes in code comments

Author: Justin Pryzby
Discussion: https://postgr.es/m/20220411020336[email protected]

Docs: Fix various mistakes and typos

Author: Justin Pryzby
Discussion: https://postgr.es/m/20220411020336[email protected]

Fix the dates of some copyright notices

0ad8032 and 4e34747 are at the origin of that.  Julien has found the one
in parse_jsontable.c, while I have spotted the rest.

Author: Julien Rouhaud, Michael Paquier
Discussion: https://postgr.es/m/20220411060838.ftnzyvflpwu6f74w@jrouhaud

Put new command-line options into alphabetical order in help output

doc: Clarify behavior of query planner locking with REINDEX

The documentation of REINDEX has never mentioned that the query planner
may take an ACCESS SHARE lock on the indexes depending on the query
used.  This adds also a note about prepared queries not impacted when
they do not use the index(es) rebuilt.

Author: Frédéric Yhuel
Reviewed-by: Guillaume Lelarge, Justin Pryzby
Discussion: https://postgr.es/m/65d08718-6f11-978a-4b5a-72b807d4c663@dalibo.com

Doc: fix typos in documentation

Commits 39969e2a1e4 and 5c279a6d350 accidentally included a typo each
in the user facing documentation.

Doc: reformat descriptions of pgbench output formats.

This is mostly driven by trying to get rid of line-too-wide
warnings in PDF output; but I think converting to a <variablelist>
makes it more readable anyway.

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

Fix pgperlsyncheck following SSL TAP test refactoring

Commit 4a7e964fc6 made pgperlsyncheck fail, but apparently nobody
noticed, although the buildfarm module that does more or less the same
thing was modified. So fix the in-core test. I will look at unifying the
two sets of tests so we avoid a future mismatch.

Add timestamp and elapsed time decorations to TAP test logs

These apply to traces from Test::More functions such as ok(), is(),
diag() and note(). Output from other sources (e.g. external programs
such a initdb) is not affected. The elapsed time is the time since the
last such trace (or the beginning of the test in the first case). Times
and timestamps are at millisecond precision.

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

Doc: shorten JSON_SERIALIZE example to avoid a PDF build warning.

There's no particular reason why this example has to use a
3-element array rather than 2-element.  Shortening it makes
the result bytea narrow enough to not cause a margin overrun
in A4 format.

Fix whitespace

Add missing serial commas

Add missing source files to nls.mk

Silence compiler warnings for unsupported compression methods.

wrasse, at least, moans about the lack of any "return" statement
in these functions.  You'd think pretty much everything would
know that exit(1) doesn't return, but evidently not.

Improve frontend error logging style.

Get rid of the separate "FATAL" log level, as it was applied
so inconsistently as to be meaningless.  This mostly involves
s/pg_log_fatal/pg_log_error/g.

Create a macro pg_fatal() to handle the common use-case of
pg_log_error() immediately followed by exit(1).  Various
modules had already invented either this or equivalent macros;
standardize on pg_fatal() and apply it where possible.

Invent the ability to add "detail" and "hint" messages to a
frontend message, much as we have long had in the backend.

Except where rewording was needed to convert existing coding
to detail/hint style, I have (mostly) resisted the temptation
to change existing message wording.

Patch by me.  Design and patch reviewed at various stages by
Robert Haas, Kyotaro Horiguchi, Peter Eisentraut and
Daniel Gustafsson.

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

Fix busted .gitignore entry.

Typo in commit 2258e76f9.

Rename delayChkpt to delayChkptFlags.

Before commit 412ad7a55639516f284cd0ef9757d6ae5c7abd43, delayChkpt
was a Boolean. Now it's an integer. Extensions using it need to be
appropriately updated, so let's rename the field to make sure that
a hard compilation failure occurs.

Replacing delayChkpt with delayChkptFlags made a few comments extend
past 80 characters, so I reflowed them and changed some wording very
slightly.

The back-branches will need a different change to restore compatibility
with existing minor releases; this is just for master.

Per suggestion from Tom Lane.

Discussion: http://postgr.es/m/a7880f4d-1d74-582a-ada7-dad168d046d1@enterprisedb.com

psql: Fix translation marking

Commit 5a2832465fd8984d089e8c44c094e6900d987fcd added
addFooterToPublicationDesc() as a wrapper around
printTableAddFooter().  The translation marker _() was moved to the
body of addFooterToPublicationDesc(), but addFooterToPublicationDesc()
was not added to GETTEXT_TRIGGERS, so those strings were lost for
translation.  To fix, add the translation markers to the call sites of
addFooterToPublicationDesc() and remove the translation marker from
the body of the function.  This seems easiest since there were only
two callers and it keeps the API consistent with
printTableAddFooter().  While we're here, add some const decorations
to the prototype of addFooterToPublicationDesc() for consistency with
printTableAddFooter().

Apply PGDLLIMPORT markings broadly.

Up until now, we've had a policy of only marking certain variables
in the PostgreSQL header files with PGDLLIMPORT, but now we've
decided to mark them all. This means that extensions running on
Windows should no longer operate at a disadvantage as compared to
extensions running on Linux: if the variable is present in a header
file, it should be accessible.

Discussion: http://postgr.es/m/CA+TgmoYanc1_FSfimhgiWSqVyP5KKmh5NP2BWNwDhO8Pg2vGYQ@mail.gmail.com

Helper script to apply PGDLLIMPORT markings.

This script isn't terribly smart and won't necessarily catch every
case, but it catches many of them and is better than a totally
manual approach.

Patch by me, reviewed by Andrew Dunstan.

Discussion: http://postgr.es/m/CA+TgmoYanc1_FSfimhgiWSqVyP5KKmh5NP2BWNwDhO8Pg2vGYQ@mail.gmail.com

Add JIT counters to pg_stat_statements

This adds cumulative counters for jit operations to pg_stat_statements,
making it easier to diagnose how JIT is used in an installation.

These changes merge into the 1.10 changes applied in 76cbf7edb6 without
creating a new version.

Reviewed-By: Julien Rouhaud
Discussion: https://www.postgresql.org/message-id/flat/CABUevEySt4NTYqvWzwyAW_0-jG1bjN-y+tykapAnA0FALOs+Lw@mail.gmail.com

Fix buildfarm failures in pg_walinspect tests.

Check XLogRecHasBlockRef() before XLogRecHasBlockImage().

Trial fix of buildfarm failures on kestrel and tamandua.

Fix buildfarm failure from commit 2258e76f90.

Add contrib/pg_walinspect.

Provides similar functionality to pg_waldump, but from a SQL interface
rather than a separate utility.

Author: Bharath Rupireddy
Reviewed-by: Greg Stark, Kyotaro Horiguchi, Andres Freund, Ashutosh Sharma, Nitin Jadhav, RKN Sai Krishna
Discussion: https://postgr.es/m/CALj2ACUGUYXsEQdKhEdsBzhGEyF3xggvLdD8C0VT72TNEfOiog%40mail.gmail.com

Remove error message hints mentioning configure options

These are usually not useful since users will use packaged
distributions and won't be interested in rebuilding their installation
from source.  Also, we have only used these kinds of hints for some
features and in some places, not consistently throughout.

Reviewed-by: Andres Freund <[email protected]>
Reviewed-by: Daniel Gustafsson <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/2552aed7-d0e9-280a-54aa-2dc7073f371d%40enterprisedb.com

pgstat: Update docs to match the shared memory stats reality.

This includes removing documentation for stats_temp_directory, adding
documentation for stats_fetch_consistency, rephrasing references to the stats
collector and documenting that starting a cleanly shut down standby will not
remove stats anymore. The latter point might require further wordsmithing, it
wasn't easy to adjust some of the existing content.

Author: Kyotaro Horiguchi <[email protected]>
Author: Andres Freund <[email protected]>
Reviewed-By: Thomas Munro <[email protected]>
Reviewed-By: Justin Pryzby <[email protected]>
Reviewed-By: "David G. Johnston" <[email protected]>
Reviewed-By: Lukas Fittl <[email protected]>
Discussion: https://postgr.es/m/20220303021600[email protected]

pg_stat_statements: Track I/O timing for temporary file blocks

This commit adds two new columns to pg_stat_statements, called
temp_blk_read_time and temp_blk_write_time.  Those columns respectively
show the time spent to read and write temporary file blocks on disk,
whose tracking has been added in efb0ef9.  This information is
available when track_io_timing is enabled, like blk_read_time and
blk_write_time.

pg_stat_statements is updated to version to 1.10 as an effect of the
newly-added columns.  Tests for the upgrade path 1.9->1.10 are added.

PGSS_FILE_HEADER is bumped for the new stats file format.

Author: Masahiko Sawada
Reviewed-by: Georgios Kokolatos, Melanie Plageman, Julien Rouhaud,
Ranier Vilela
Discussion: https://postgr.es/m/CAD21AoAJgotTeP83p6HiAGDhs_9Fw9pZ2J=_tYTsiO5Ob-V5GQ@mail.gmail.com