doc: Fix example command for ALTER FOREIGN TABLE ... OPTIONS.

In the documentation, previously the example command for
ALTER FOREIGN TABLE ... OPTIONS incorrectly included both
the option name and value with the DROP operation.
The correct syntax for the DROP operation requires only
the name of the option to be specified. This commit fixes
the example by removing the option value from the DROP operation.

Back-patch to all supported versions.

Author: Mehmet Emin KARAKAS <[email protected]>
Reviewed-by: Fujii Masao
Discussion: https://postgr.es/m/CANQrdXAHzbcEYhjGoe5A42OmfvdQhHFJzyKj9gJvHuDKyOF5Ng@mail.gmail.com

Don't use _BitScanForward64/_BitScanReverse64 on 32-bit MSVC builds

677319746 added support for making use of MSVC's bit scanning functions.
However, that commit failed to consider 32-bit MSVC builds where the
64-bit versions of these functions are unavailable.  This resulted in
compilation failures on 32-bit MSVC.

Here we adjust the code so we fall back on the manual way of finding the
bit positions for 64-bit integers when building on 32-bit MSVC.

Bug: #17967
Reported-by: Youmiu Mo
Discussion: https://postgr.es/m/17967-cd21e34a314141b2@postgresql.org

Use per-tuple context in ExecGetAllUpdatedCols

Commit fc22b6623b (generated columns) replaced ExecGetUpdatedCols() with
ExecGetAllUpdatedCols() in a couple places handling UPDATE (triggers and
lock mode). However, ExecGetUpdatedCols() did exec_rt_fetch() while
ExecGetAllUpdatedCols() also allocates memory through bms_union()
without paying attention to the memory context and happened to use the
long-lived ExecutorState, leaking the memory until the end of the query.

The amount of leaked memory is proportional to the number of (updated)
attributes, types of UPDATE triggers, and the number of processed rows
(which for UPDATE ... FROM ... may be much higher than updated rows).

Fixed by switching to the per-tuple context in GetAllUpdatedColumns().
This is fine for all in-core callers, but external callers may need to
copy the result. But we're not aware of any such callers.

Note the issue was introduced by fc22b6623b, but the macros were later
renamed by f50e888990.

Backpatch to 12, where the issue was introduced.

Reported-by: Tomas Vondra
Reviewed-by: Andres Freund, Tom Lane, Jakub Wartak
Backpatch-through: 12
Discussion: https://postgr.es/m/222a3442-7f7d-246c-ed9b-a76209d19239@enterprisedb.com

doc: Fix confusing positioning of notes in connection settings

Reported-by: Jonathan S. Katz <[email protected]>
Reviewed-by: Daniel Gustafsson <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/6f825d42-a1ce-492a-2ea7-c83e6e65fa8b%40postgresql.org

Remove read-only server settings lc_collate and lc_ctype

The GUC settings lc_collate and lc_ctype are from a time when those
locale settings were cluster-global.  When those locale settings were
made per-database (PG 8.4), the settings were kept as read-only.  As
of PG 15, you can use ICU as the per-database locale provider, so
examining these settings is already less meaningful and possibly
confusing, since you need to look into pg_database to find out what is
really happening, and they would likely become fully obsolete in the
future anyway.

Reviewed-by: Jeff Davis <[email protected]>
Discussion: https://www.postgresql.org/message-id/696054d1-bc88-b6ab-129a-18b8bce6a6f0@enterprisedb.com

Reload configuration more frequently in apply worker.

The apply worker was not reloading the configuration while processing
messages if there is a continuous flow of messages from upstream. It was
also not reloading the configuration if there is a change in the
configuration after it has waited for the message and before receiving the
new replication message. This can lead to failure in tests because we
expect that after reload, the behavior of apply worker to respect the
changed GUCs.

We found this while analyzing a rare buildfarm failure.

Author: Hou Zhijie
Reviewed-by: Amit Kapila
Discussion: https://postgr.es/m/OS0PR01MB5716AF9079CC0755CD015322947E9@OS0PR01MB5716.jpnprd01.prod.outlook.com

Initialize 'recordXtime' to silence compiler warning.

In reality, recordXtime will always be set by the getRecordTimestamp
call, but the compiler doesn't necessarily see that.

Back-patch to all supported versions.

Author: Tristan Partin
Discussion: https://www.postgresql.org/message-id/CT5MN8E11U0M.1NYNCHXYUHY41@gonk

doc:  PG 16 relnotes, fix PREPARE/EXECUTE wording

Reported-by: Erik Rijkers
Discussion: https://postgr.es/m/73f361d0-237e-3413-224b-86ab6b71a3dd@xs4all.nl

Remove obsolete comment

OIDs are no longer system columns, since 578b229718.

Doc: unify use of timestamp with time zone vs timestamptz

For pg_stat_all_tables, last_vacuum, last_autovacuum and co all used the
full "timestamp with time zone" type name.  For consistency, make the
newly added "last_seq_scan" also use the full type name instead of
"timestamptz".

Author: Noriyoshi Shinoda
Discussion: https://postgr.es/m/DM4PR84MB17348EA11FA90A9BE896AF89EE489%40DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM

Doc: explain about dependency tracking for new-style SQL functions.

5.14 Dependency Tracking was not updated when we added new-style
SQL functions.  Improve that.

Noted by Sami Imseih.  Back-patch to v14 where
new-style SQL functions came in.

Discussion: https://postgr.es/m/2C1933AB-C2F8-499B-9D18-4AC1882256A0@amazon.com

Fix pg_dump's failure to honor dependencies of SQL functions.

A new-style SQL function can contain a parse-time dependency
on a unique index, much as views and matviews can (such cases
arise from GROUP BY and ON CONFLICT clauses, for example).
To dump and restore such a function successfully, pg_dump must
postpone the function until after the unique index is created,
which will happen in the post-data part of the dump.  Therefore
we have to remove the normal constraint that functions are
dumped in pre-data.  Add code similar to the existing logic
that handles this for matviews.  I added test cases for both
as well, since code coverage tests showed that we weren't
testing the matview logic.

Per report from Sami Imseih.  Back-patch to v14 where
new-style SQL functions came in.

Discussion: https://postgr.es/m/2C1933AB-C2F8-499B-9D18-4AC1882256A0@amazon.com

Fix misuse of pg_log_info() for details/hints.

Two places in pg_dump_sort.c were using pg_log_info() to add
more details to a message printed with pg_log_warning().
This is bad, because at default verbosity level we would
print the warning line but not the details.  One should use
pg_log_warning_detail() or pg_log_warning_hint() instead.
Commit 9a374b77f got rid of most such abuses, but unaccountably
missed these.

Noted while studying a bug report from Sami Imseih.
Back-patch to v15 where 9a374b77f came in.  (Prior versions
don't have the missing-details misbehavior, for reasons
I didn't bother to track down.)

Discussion: https://postgr.es/m/2C1933AB-C2F8-499B-9D18-4AC1882256A0@amazon.com

doc: Add note to prevent server spoofing with SCRAM

The set of recommendations added in the documentation with this commit
helps in avoiding SCRAM exchanges with untrusted servers.

Author: Jacob Champion, Jonathan Katz
Reviewed-by: Stephen Frost, Daniel Gustafsson, Michael Paquier
Discussion: https://postgr.es/m/CAAWbhmg5Gh0JetNbQi7z0yOsdsN9YECv8GoY-QBGBBiip9+JOw@mail.gmail.com

doc:  PG 16 relnotes, add psql \df+ source code change

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

doc:  add missing "the" in LATERAL sentence.

Backpatch-through: 11

doc:  PG 16 relnotes, move memory item and reword OUTER item

Reported-by: David Rowley
Discussion: https://postgr.es/m/CAApHDvqmqxcX2n9NwvsfnsN0be6DjmyLSjz3Jk2DaZO5OLW+pw@mail.gmail.com

doc:  PG 16 relnotes, add memory overhead reduction item

Reported-by: David Rowley
Discussion: https://postgr.es/m/CAApHDvqnUoyrJxS4uqnKo87b3_cUjaDDte4NQag49YHu1oEOgA@mail.gmail.com

doc:  PG 16 relnotes, adjust subscription origin mention

Reported-by: Masahiko Sawada
Discussion: https://postgr.es/m/CAD21AoC+VihMWs3-xVB3Z=8LzLbsQc52TO29o25rzfqcnJDCUQ@mail.gmail.com

doc:  PG 16 relnotes, adjust auto_explain logging item

Reported-by: Dagfinn Ilmari Mannsåker
Discussion: https://postgr.es/m/[email protected]

doc: Add missing backend_type to pg_stat_activity

Commit 0c679464a8 added the missing backendDesc for B_STANDALONE_BACKEND
but missed updating the list of backend types in the documentation.  Fix
by adding it to the list.

Author: Noriyoshi Shinoda <[email protected]>
Discussion: https://postgr.es/m/DM4PR84MB1734ECEA02BCB59564E8FC03EE4A9@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM

doc: PG 16 relnotes: adjust outer/full hash join parallelization

Reported-by: David Rowley
Discussion: https://postgr.es/m/CAApHDvph4djrP+zjOK67VcgbB_p9Zn8QoO7Qctt4oQgUC_ejEw@mail.gmail.com

doc:  PG 16 relnotes, fix duplicate author and commit

Reported-by: Masahiko Sawada
Discussion: https://postgr.es/m/CAD21AoALE_joh=H-j5sdaAfDs=BXtCy6BQKYZBTi=neU8k0VFw@mail.gmail.com

doc:  PG 16 relnotes, fix "locale" typo and windows locale text

Reported-by: Laurenz Albe, Álvaro Herrera
Discussion: https://postgr.es/m/70a09a9fa557b632f4b1505395aaa6c4cb77b55a[email protected]

ICU: use uloc_getDefault() for initdb.

Simpler, and better preserves the locale name as read from the
environment.

Author: Daniel Verite
Discussion: https://postgr.es/m/a6204a46-c077-451b-8f9d-8965d95bb57c@manitou-mail.org

Fix joinclause removal logic to cope with cloned clauses.

When we're deleting a no-op LEFT JOIN from the query, we must remove
the join's joinclauses from surviving relations' joininfo lists.
The invention of "cloned" clauses in 2489d76c4 broke the logic for
that; it'd fail to remove clones that include OJ relids outside the
doomed join's min relid sets, which could happen if that join was
previously discovered to commute with some other join.

This accidentally failed to cause problems in the majority of cases,
because we'd never decide that such a cloned clause was evaluatable at
any surviving join.  However, Richard Guo discovered a case where that
did happen, leading to "no relation entry for relid" errors later.
Also, adding assertions that a non-removed clause contains no Vars from
the doomed join exposes that there are quite a few existing regression
test cases where the problem happens but is accidentally not exposed.

The fix for this is just to include the target join's commute_above_r
and commute_below_l sets in the relid set we test against when
deciding whether a join clause is "pushed down" and thus not
removable.

While at it, do a little refactoring: the join's relid set can be
computed inside remove_rel_from_query rather than in the caller.

Patch by me; thanks to Richard Guo for review.

Discussion: https://postgr.es/m/CAMbWs4_PHrRqTKDNnTRsxxQy6BtYCVKsgXm1_gdN2yQ=kmcO5g@mail.gmail.com

Doc fixes for commit 1e16af8ab5.

Discussion: https://postgr.es/m/275c47ea-e7f3-e654-c99a-63bc116997d7@enterprisedb.com

nbtree VACUUM: cope with right sibling link corruption.

Avoid "right sibling's left-link doesn't match" errors when vacuuming a
corrupt nbtree index.  Just LOG the issue and press on.  That way VACUUM
will have a decent chance of finishing off all required processing for
the index (and for the table as a whole).

This error was seen in the field from time to time (it's more than a
theoretical risk), so giving VACUUM the ability to press on like this
has real value.  Nothing short of a REINDEX is expected to fix the
underlying index corruption, so giving up (by throwing an error) risks
making a bad situation far worse.  Anything that blocks forward progress
by VACUUM like this might go unnoticed for a long time.  This could
eventually lead to a wraparound/xidStopLimit outage.

Note that _bt_unlink_halfdead_page() has always been able to bail on
page deletion when the target page's left sibling page was in an
inconsistent state.  It now does the same thing (returns false to back
out of the second phase of deletion) when it notices sibling link
corruption in the target page's right sibling page.

This is similar to the work from commit 5b861baa (later backpatched as
commit 43e409ce), which taught nbtree to press on with vacuuming an
index when page deletion fails to "re-find" a downlink in the target
page's parent page.  The "re-find" check seems to make VACUUM bail on
page deletion more often in practice, but there is no reason to take any
chances here.

Author: Peter Geoghegan <[email protected]>
Reviewed-By: Heikki Linnakangas <[email protected]>
Discussion: https://postgr.es/m/CAH2-Wzko2q2kP1+UvgJyP9g0mF4hopK0NtQZcxwvMv9_ytGhkQ@mail.gmail.com
Backpatch: 11- (all supported versions).

Fix filtering of "cloned" outer-join quals some more.

We've had multiple issues with the clause_is_computable_at logic that
I introduced in 2489d76c4: it's been known to accept more than one
clone of the same qual at the same plan node, and also to accept no
clones at all.  It's looking impractical to get it 100% right on the
basis of the currently-stored information, so fix it by introducing a
new RestrictInfo field "incompatible_relids" that explicitly shows
which outer joins a given clone mustn't be pushed above.

In principle we could populate this field in every RestrictInfo, but
that would cost space and there doesn't presently seem to be a need
for it in general.  Also, while deconstruct_distribute_oj_quals can
easily fill the field with the remaining members of the commutative
join set that it's considering, computing it in the general case
seems again pretty complicated.  So for now, just fill it for
clone quals.

Along the way, fix a bug that may or may not be only latent:
equivclass.c was generating replacement clauses with is_pushed_down
and has_clone/is_clone markings that didn't match their
required_relids.  This led me to conclude that leaving the clone flags
out of make_restrictinfo's purview wasn't such a great idea after all,
so add them.

Per report from Richard Guo.

Discussion: https://postgr.es/m/CAMbWs48EYi_9-pSd0ORes1kTmTeAjT4Q3gu49hJtYCbSn2JyeA@mail.gmail.com

doc: fix typo in language tag documentation

Commit 1e16af8ab5 accidentally mistyped 'language' in one place.

doc: Fix example query for pg_walinspect

The LIMIT clause had ended up in the wrong place in the query.
Backpatch to v15 where pg_walinspect was introduced.

Reported-by: Jian He <[email protected]>
Discussion: https://postgr.es/m/CACJufxHqXDr4NnmwmR6pEiVPAg54J0dgwMuYQzrH5BX6+NtF1g@mail.gmail.com
Backpatch-through: 15

Fix pgbench in prepared mode with an empty pipeline

It crashes because it references memory that's not allocated in that
particular case.  Fix by allocating it.

Reported-by: Alexander Lakhin <[email protected]>
Discussion: https://postgr.es/m/bcf802a6-afc1-95b9-7bf4-c5dd868ec144@gmail.com

Fix typo in TAP tests of vacuumdb

Noticed while scanning the area, introduced in 582edc3.

doc: PG 16 relnotes, add author from previous merge

Reported-by: John Naylor
Discussion: https://postgr.es/m/CAFBsxsEMoNdg6CCMuQ-6YJ8G=AgGNMVuiTb5Di5bsoPfBb=9CA@mail.gmail.com

doc:  PG 16 relnotes, wording adjustments

Reported-by: Erik Rijkers
Discussion: https://postgr.es/m/c4a88acf-ab1a-a912-d4a9-5e19b323c5ed@xs4all.nl

doc: PG 16 relnotes, merge and move vector items

Reported-by: John Naylor
Discussion: https://postgr.es/m/CAFBsxsEPg8L2MmGqavc8JByC=WF_Mnkhn-KKnFPkcqh0hydung@mail.gmail.com

doc: PG 16 relnotes, update xid/subxid searches item

Reported-by: John Naylor
Discussion: https://postgr.es/m/CAFBsxsEPg8L2MmGqavc8JByC=WF_Mnkhn-KKnFPkcqh0hydung@mail.gmail.com

Document deprecated createuser option.

2dcd1578c4 left the --role option undocumented, which is
inconsistent with other deprecated options such as pg_dump's
--blobs and --no-blobs.  This change adds --role back to
createuser's documentation and usage output and marks it as
deprecated.

Suggested-by: Peter Eisentraut
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/0e85c9e7-4804-1cdb-5a4a-c72c328f9ad8%40enterprisedb.com

Doc: update src/tools/pginclude/README.

Commit f62975b2a made headerscheck and cpluspluscheck a little
smarter than this documentation gave them credit for.  Make
their docs match current reality.  Also add a warning about the
layer of dust that has settled on the rest of these scripts.

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

Fix the install rule for snowball_create.sql.

This file could be in the current (build) directory if we just
built it.  However, when installing from a VPATH build from a
tarball, it will exist in the source directory and gmake will
therefore not rebuild it.  Use the $< macro to find out where
gmake found it.

Oversight in b3a0d8324, which also exposes a buildfarm testing gap:
we test install from VPATH builds from bare source trees, but not
from tarballs.

Per report from Christoph Berg.

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

Use lower case for icu_validation_level values

Similar to client_min_messages etc.

Punctuation improvement in postgresql.conf.sample

Add newline at end of file

doc:  PG 16 relnotes, SIMD improvements

Reported-by: John Naylor
Discussion: https://postgr.es/m/CAFBsxsEuAx4_nq=200u=70S5r83C2hzO-a9+c6YXTCbOFeDAfw@mail.gmail.com

Stamp 16beta1.

doc: PG 16 relnotes, add major features list

Reported-by: Jonathan Katz
Discussion: https://postgr.es/m/2fd2cc0e-df39-3e77-8fcf-35aad5796b0a@postgresql.org

Spell the values of libpq's gssdelegation parameter as "0" and "1".

That's how other boolean options are handled, so do likewise.
The previous coding with "enable" and "disable" was seemingly
modeled on gssencmode, but that's a three-way flag.

While at it, add PGGSSDELEGATION to the set of environment
variables cleared by pg_regress and Utils.pm.

Abhijit Menon-Sen, per gripe from Alvaro Herrera

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

doc:  PG 16 relnotes, improve desc. of pg_log_standby_snapshot()

Translation updates

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 642d41265b1ea68ae71a66ade5c5440ba366a890

pg_dump doc: mention 'long' is valid for --compress

Apparently an oversight in 2820adf7755d.

doc:  PG 16 relnotes, improve description of standby log. decode

Improve description of "Allow logical decoding on standbys".

Rename some createuser options.

This change renames --admin to --with-admin, --role to --member-of,
and --member to --with-member.  Many people found the previous
names to be confusing.  The --admin and --member options are new in
v16, but --role has been there for a while, so that one has been
kept (but left undocumented) for backward compatibility.

Suggested-by: Peter Eisentraut
Reviewed-by: Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/ZFvVZvQDliIWmOwg%40momjian.us

doc: PG 16 relnotes, misc merged items and bootstrap detail

Reported-by: Andres Freund, jian he
Discussion: https://postgr.es/m/20230521171341[email protected], 20230521171341[email protected]

doc:  PG 16 relnotes, misc. updates

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

In clause_is_computable_at(), test required_relids for clone clauses.

Use the clause's required_relids not clause_relids for testing
whether it is computable at the current join level, if it is a
clone clause generated by deconstruct_distribute_oj_quals().

Arguably, this is more correct and we should do it for all clauses;
that would at least remove the handwavy claim that we are doing
it to save cycles compared to inspecting Vars individually.
However, attempting to do that exposes that we are not being careful
to compute an accurate value for required_relids in all cases.
I'm unsure whether it's a good idea to attempt to do that for v16,
or leave it as future clean-up.  In the meantime, this quick hack
demonstrably fixes some cases, so let's squeeze it in for beta1.

Patch by me, but great thanks to Richard Guo for investigation
and testing.  The new test cases are all modeled on his examples.

Discussion: https://postgr.es/m/CAMbWs4-_vwkBij4XOQ5ukxUvLgwTm0kS5_DO9CicUeKbEfKjUw@mail.gmail.com

Remove over-eager assertion in ExtendBufferedRelTo()

The assertion checked that the size of the relation is not "too large" - but
the code is explicitly dealing with the possibility of another backend
extending the relation concurrently. In that case the new relation size could
be bigger than what the current backend needs, wrongly triggering an assertion
failure.

Unfortunately it is hard to write a reliable and affordable regression tests
for this, as a lot of concurrency is needed to encounter the bug.

Introduced in 31966b151e6a.

Reported-by: Melanie Plageman <[email protected]>

Optimize walsender wake up logic using condition variables

WalSndWakeup() currently loops through all the walsenders slots, with a
spinlock acquisition and release for every iteration, to wake up waiting
walsenders.

This commonly was not a problem before e101dfac3a53c. But, to allow logical
decoding on standbys, we need to wake up logical walsenders after every WAL
record is applied on the standby, rather just when flushing WAL or switching
timelines.  This causes a performance regression for workloads replaying a lot
of WAL records.

To solve this, we use condition variable (CV) to efficiently wake up
walsenders in WalSndWakeup().

Every walsender prepares to sleep on a shared memory CV. Note that it just
prepares to sleep on the CV (i.e., adds itself to the CV's waitlist), but does
not actually wait on the CV (IOW, it never calls ConditionVariableSleep()). It
still uses WaitEventSetWait() for waiting, because CV infrastructure doesn't
handle FeBe socket events currently. The processes (startup process,
walreceiver etc.)  wanting to wake up walsenders use
ConditionVariableBroadcast(), which in turn calls SetLatch(), helping
walsenders come out of WaitEventSetWait().

We use separate shared memory CVs for physical and logical walsenders for
selective wake ups, see WalSndWakeup() for more details.

This approach is simple and reasonably efficient. But not very elegant. But
for 16 it seems to be a better path than a larger redesign of the CV
mechanism.  A desirable future improvement would be to add support for CVs
into WaitEventSetWait().

This still leaves us with a small regression in very extreme workloads (due to
the spinlock acquisition in ConditionVariableBroadcast() when there are no
waiters) - but that seems acceptable.

Reported-by: Andres Freund <[email protected]>
Suggested-by: Andres Freund <[email protected]>
Author: Bharath Rupireddy <[email protected]>
Reviewed-by: "Drouvot, Bertrand" <[email protected]>
Reviewed-by: Zhijie Hou <[email protected]>
Discussion: https://www.postgresql.org/message-id/20230509190247.3rrplhdgem6su6cg%40awork3.anarazel.de

doc:  PG 16 relnotes,  add commits

Reported-by: Ian Lawrence Barwick
Discussion: https://postgr.es/m/CAB8KJ=hLvQDb53WdigV7OBEBh5tzQ7eA=pG0ZpccoRVBUNCXYA@mail.gmail.com

Doc: fix some rendering problems in the PDF docs build.

Tweak column widths in a couple of tables to avoid "contents
... exceed the available area" warnings.  Remove usage of
some non-Latin-1 characters.

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

Expand some more uses of "deleg" to "delegation" or "delegated".

Complete the task begun in 9c0a0e2ed: we don't want to use the
abbreviation "deleg" for GSS delegation in any user-visible places.
(For consistency, this also changes most internal uses too.)

Abhijit Menon-Sen and Tom Lane

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

Fix remaining references to gss_accept_deleg.

These were missed in 9c0a0e2ed9.

Discussion: https://postgr.es/m/20230521031757.GA3835667%40nathanxps13

rename "gss_accept_deleg" to "gss_accept_delegation".

This is more consistent with existing GUC spelling.

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

doc:  PG 16 relnotes, misc updates

*  document to_reg* accepting OIDs
*  document pg_log_standby_snapshot()
*  document pg_input_is_valid() and pg_input_error_info()
*  handle rename of function to pg_split_walfile_name()
*  fix character encoding problem for Przemyslaw Sztoch
*  remove partition section

Reported-by: jian he, Tom Lane, Bertrand Drouvot

Add 0245f8db3 to .git-blame-ignore-revs.

Pre-beta mechanical code beautification.

Run pgindent, pgperltidy, and reformat-dat-files.

This set of diffs is a bit larger than typical.  We've updated to
pg_bsd_indent 2.1.2, which properly indents variable declarations that
have multi-line initialization expressions (the continuation lines are
now indented one tab stop).  We've also updated to perltidy version
20230309 and changed some of its settings, which reduces its desire to
add whitespace to lines to make assignments etc. line up.  Going
forward, that should make for fewer random-seeming changes to existing
code.

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

Make agreed-on updates in perltidy options.

Our standard version of perltidy is now 20230309.
Add a --valign-exclusion-list setting to reduce crosstalk
between nearby lines of Perl code.

Also, update instructions for running pgindent
(missed in b16259b3c).

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

Do pre-release housekeeping on catalog data.

Run renumber_oids.pl to move high-numbered OIDs down, as per pre-beta
tasks specified by RELEASE_CHANGES.  For reference, the command was

./renumber_oids.pl --first-mapped-oid 8000 --target-oid 6200

Fix thinko in join removal.

In commit 9df8f903e I (tgl) switched join_is_removable() from
using the min relid sets of the join under consideration to
using its full syntactic relid sets.  This was a mistake,
as it allowed join removal in cases where a reference to the
join output would survive in some syntactically-lower join
condition.  Revert to the former coding.

Richard Guo

Discussion: https://postgr.es/m/CAMbWs4-EU9uBGSP7G-iTwLBhRQ=rnZKvFDhD+n+xhajokyPCKg@mail.gmail.com

Fix misbehavior of EvalPlanQual checks with multiple result relations.

The idea of EvalPlanQual is that we replace the query's scan of the
result relation with a single injected tuple, and see if we get a
tuple out, thereby implying that the injected tuple still passes the
query quals.  (In join cases, other relations in the query are still
scanned normally.)  This logic was not updated when commit 86dc90056
made it possible for a single DML query plan to have multiple result
relations, when the query target relation has inheritance or partition
children.  We replaced the output for the current result relation
successfully, but other result relations were still scanned normally;
thus, if any other result relation contained a tuple satisfying the
quals, we'd think the EPQ check passed, even if it did not pass for
the injected tuple itself.  This would lead to update or delete
actions getting performed when they should have been skipped due to
a conflicting concurrent update in READ COMMITTED isolation mode.

Fix by blocking all sibling result relations from emitting tuples
during an EvalPlanQual recheck.  In the back branches, the fix is
complicated a bit by the need to not change the size of struct
EPQState (else we'd have ABI-breaking changes in offsets in
struct ModifyTableState).  Like the back-patches of 3f7836ff6
and 4b3e37993, add a separately palloc'd struct to avoid that.
The logic is the same as in HEAD otherwise.

This is only a live bug back to v14 where 86dc90056 came in.
However, I chose to back-patch the test cases further, on the
grounds that this whole area is none too well tested.  I skipped
doing so in v11 though because none of the test applied cleanly,
and it didn't quite seem worth extra work for a branch with only
six months to live.

Per report from Ante Krešić (via Aleksander Alekseev)

Discussion: https://postgr.es/m/CAJ7c6TMBTN3rcz4=AjYhLPD_w3FFT0Wq_C15jxCDn8U4tZnH1g@mail.gmail.com

psql: Tweak xheader_width and pager_min_lines input parsing

Don't throw away the previous value when an invalid value is proposed.

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

Message style improvements

doc:  PG 16 relnotes, delete reverted grant, adjust version num

Reported-by: Nathan Bossart, Sehrope Sarkuni

Allocate hash join files in a separate memory context

Should a hash join exceed memory limit, the hashtable is split up into
multiple batches. The number of batches is doubled each time a given
batch is determined not to fit in memory. Each batch file is allocated
with a block-sized buffer for buffering tuples and parallel hash join
has additional sharedtuplestore accessor buffers.

In some pathological cases requiring a lot of batches, often with skewed
data, bad stats, or very large datasets, users can run out-of-memory
solely from the memory overhead of all the batch files' buffers.

Batch files were allocated in the ExecutorState memory context, making
it very hard to identify when this batch explosion was the source of an
OOM. This commit allocates the batch files in a dedicated memory
context, making it easier to identify the cause of an OOM and work to
avoid it.

Based on initial draft by Tomas Vondra, with significant reworks and
improvements by Jehan-Guillaume de Rorthais.

Author: Jehan-Guillaume de Rorthais <[email protected]>
Author: Tomas Vondra <[email protected]>
Reviewed-by: Melanie Plageman <[email protected]>
Discussion: https://postgr.es/m/20190421114618.z3mpgmimc3rmubi4@development
Discussion: https://postgr.es/m/20230504193006.1b5b9622%40karst#273020ff4061fc7a2fbb1ba96b281f17

Describe hash join implementation

Add a high level description of our implementation of the hybrid hash
join algorithm to the block comment in nodeHashjoin.c.

Author: Melanie Plageman <[email protected]>
Reviewed-by: Tomas Vondra <[email protected]>
Reviewed-by: Jehan-Guillaume de Rorthais <[email protected]>
Discussion: https://postgr.es/m/20230516160051.4267a800%40karst

Avoid naming conflict between transactions.sql and namespace.sql.

Commits 681d9e462 et al added a test case in namespace.sql that
implicitly relied on there not being a table "public.abc".
However, the concurrently-run transactions.sql test creates precisely
such a table, so with the right timing you'd get a failure.
Creating a table named as generically as "abc" in a common schema
seems like bad practice, so fix this by changing the name of
transactions.sql's table.  (Compare 2cf8c7aa4.)

Marina Polyakova

Discussion: https://postgr.es/m/80d0201636665d82185942e7112257b4@postgrespro.ru

Remove stray mid-sentence tabs in comments

doc:  PG 16 relnotes, merge REINDEX and reindexdb items

Reported-by: Vibhor Kumar

doc:  PG 16 relnotes, add missing parentheses

Reported-by: Hans Buschmann

Move mdwriteback() to better place

The previous order in the file didn't make sense and matched neither
the header file nor the smgr API.

Discussion: https://www.postgresql.org/message-id/flat/22fed8ba-01c3-2008-a256-4ea912d68fab%40enterprisedb.com

Reindent some comments

Most (older) comments in md.c and smgr.c are indented with a leading
tab on all lines, which isn't the current style and makes updating the
comments a bit annoying.  This reindents all these lines with a single
space, as is the normal style.  This issue exists in various shapes
throughout the code but it's pretty consistent here, and since there
is a patch pending to refresh some of the comments in these files, it
seems sensible to clean this up here separately.

Discussion: https://www.postgresql.org/message-id/flat/22fed8ba-01c3-2008-a256-4ea912d68fab%40enterprisedb.com

pageinspect: Fix gist_page_items() with included columns

Non-leaf pages of GiST indexes contain key attributes, leaf pages
contain both key and non-key attributes, and gist_page_items() ignored
the handling of non-key attributes.  This caused a few problems when
using gist_page_items() on a GiST index with INCLUDE:
- On a non-leaf page, the function would crash.
- On a leaf page, the function would work, but miss to display all the
values for included attributes.

This commit fixes gist_page_items() to handle such cases in a more
appropriate way, and now displays the values of key and non-key
attributes for each item separately in a style consistent with what
ruleutils.c would generate for the attribute list, depending on the page
type dealt with.  In a way similar to how a record is displayed, values
would be double-quoted for key or non-key attributes if required.

ruleutils.c did not provide a routine able to control if non-key
attributes should be displayed, so an extended() routine for index
definitions is added to work around the leaf and non-leaf page
differences.

While on it, this commit fixes a third problem related to the amount of
data reported for key attributes.  The code originally relied on
BuildIndexValueDescription() (used for error reports on constraints)
that would not print all the data stored in the index but the index
opclass's input type, so this limited the amount of information
available.  This switch makes gist_page_items() much cheaper as there is
no need to run ACL checks for each item printed, which is not an issue
anyway as superuser rights are required to execute the functions of
pageinspect.  Opclasses whose data cannot be displayed can rely on
gist_page_items_bytea().

The documentation of this function was slightly incorrect for the
output results generated on HEAD and v15, so adjust it on these
branches.

Author: Alexander Lakhin, Michael Paquier
Discussion: https://postgr.es/m/17884-cb8c326522977acb@postgresql.org
Backpatch-through: 14

doc:  improve pg_walinspect and role membership items

Reported-by: Peter Geoghegan

doc:  improve description of adding roles as members

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

doc:  update PG 16 relnotes for pg_walinspect changes

Reported-by: Peter Geoghegan

Show empty BRIN ranges in brin_page_items

Commit 3581cbdcd6 added a flag to identify empty BRIN ranges. This adds
the new flag to brin_page_items() output.

This is kept as a separate commit as it should not be backpatched.

Reviewed-by: Justin Pryzby, Matthias van de Meent, Alvaro Herrera
Discussion: https://postgr.es/m/402430e4-7d9d-6cf1-09ef-464d80afff3b@enterprisedb.com

Fix handling of empty ranges and NULLs in BRIN

BRIN indexes did not properly distinguish between summaries for empty
(no rows) and all-NULL ranges, treating them as essentially the same
thing. Summaries were initialized with allnulls=true, and opclasses
simply reset allnulls to false when processing the first non-NULL value.
This however produces incorrect results if the range starts with a NULL
value (or a sequence of NULL values), in which case we forget the range
contains NULL values when adding the first non-NULL value.

This happens because the allnulls flag is used for two separate
purposes - to mark empty ranges (not representing any rows yet) and
ranges containing only NULL values.

Opclasses don't know which of these cases it is, and so don't know
whether to set hasnulls=true. Setting the flag in both cases would make
it correct, but it would also make BRIN indexes useless for queries with
IS NULL clauses. All ranges start empty (and thus allnulls=true), so all
ranges would end up with either allnulls=true or hasnulls=true.

The severity of the issue is somewhat reduced by the fact that it only
happens when adding values to an existing summary with allnulls=true.
This can happen e.g. for small tables (because a summary for the first
range exists for all BRIN indexes), or for tables with large fraction of
NULL values in the indexed columns.

Bulk summarization (e.g. during CREATE INDEX or automatic summarization)
that processes all values at once is not affected by this issue. In this
case the flags were updated in a slightly different way, not forgetting
the NULL values.

To identify empty ranges we use a new flag, stored in an unused bit in
the BRIN tuple header so the on-disk format remains the same. A matching
flag is added to BrinMemTuple, into a 3B gap after bt_placeholder.
That means there's no risk of ABI breakage, although we don't actually
pass the BrinMemTuple to any public API.

We could also skip storing index tuples for empty summaries, but then
we'd have to always process such ranges - even if there are no rows in
large parts of the table (e.g. after a bulk DELETE), it would still
require reading the pages etc. So we store them, but ignore them when
building the bitmap.

Backpatch to 11. The issue exists since BRIN indexes were introduced in
9.5, but older releases are already EOL.

Backpatch-through: 11
Reviewed-by: Justin Pryzby, Matthias van de Meent, Alvaro Herrera
Discussion: https://postgr.es/m/402430e4-7d9d-6cf1-09ef-464d80afff3b@enterprisedb.com

doc:  PG 16 relnotes, add freeze and update walinspect items

Reported-by: Peter Geoghegan

docs:  re-order some PG 16 relnotes items

Reported-by: Jonathan Katz

doc:  more PG 16 relnote wording improvements

Fix handling of NULLs when merging BRIN summaries

When merging BRIN summaries, union_tuples() did not correctly update the
target hasnulls/allnulls flags. When merging all-NULL summary into a
summary without any NULL values, the result had both flags set to false
(instead of having hasnulls=true).

This happened because the code only considered the hasnulls flags,
ignoring the possibility the source summary has allnulls=true.

Discovered while investigating issues with handling empty BRIN ranges
and handling of NULL values, but it's a separate problem (has nothing to
do with empty ranges).

Fixed by considering both flags on the source summary, and updating the
hasnulls flag on the target summary.

Backpatch to 11. The bug exists since 9.5 (where BRIN indexes were
introduced), but those releases are EOL already.

Discussion: https://postgr.es/m/9d993d0d-e431-2196-9ccc-0554d0e60154%40enterprisedb.com

doc:  add more sections to PG 16 release notes

doc:  first draft of the PG 16 release notes

Fix documentation build broken by 1e16af8ab5.

Doc improvements for language tags and custom ICU collations.

Separate the documentation for language tags themselves from the
available collation settings which can be included in a language tag.

Include tables of the available options, more details about the
effects of each option, and additional examples.

Also include an explanation of the "levels" of textual features and
how they relate to collation.

Discussion: https://postgr.es/m/25787ec7-4c04-9a8a-d241-4dc9be0b1ba3@postgresql.org
Reviewed-by: Jonathan S. Katz

Tweak API of new function clause_is_computable_at().

Pass it the RestrictInfo under consideration, not just the
clause_relids.  This should save some trivial amount of
code at the call sites, and it gives us more flexibility
about what clause_is_computable_at() does.  There's no
actual functional change here, though.

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

ICU: check for U_STRING_NOT_TERMINATED_WARNING.

Fixes memory error in cases where the length of the language name
returned by uloc_getLanguage() is exactly ULOC_LANG_CAPACITY, in which
case the status is set to U_STRING_NOT_TERMINATED_WARNING.

Also check in call sites for other ICU functions that are expected to
return a C string to be safe (no bug is known at these other call
sites).

Reported-by: Alexander Lakhin
Discussion: https://postgr.es/m/2098874d-c111-41e4-9063-30bcf135226b@gmail.com

Reduce icu_validation_level default to WARNING.

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

Fix error message wordings

The original patch for percentrepl.c c96de2ce17 adopted the error
messages from basebackup_to_shell, but that uses terminology that
doesn't really fit with the new API naming.

Add writeback to pg_stat_io

28e626bde00 added the concept of IOOps but neglected to include writeback
operations. ac8d53dae5 added time spent doing these I/O operations. Without
counting writeback, checkpointer write time in the log often differed
substantially from that in pg_stat_io. To fix this, add IOOp IOOP_WRITEBACK
and track writeback in pg_stat_io.

Bumps catversion.

Author: Melanie Plageman <[email protected]>
Reviewed-by: Kyotaro Horiguchi <[email protected]>
Reported-by: Andres Freund <[email protected]>
Discussion: https://postgr.es/m/20230419172326.dhgyo4wrrhulovt6%40awork3.anarazel.de

Update parameter name context to wb_context

For clarity of review, renaming the function parameter "context" in
ScheduleBufferTagForWriteback() and IssuePendingWritebacks() to
"wb_context" is a separate commit. The next commit adds an "io_context"
parameter and "wb_context" makes it more clear which is which.

Author: Melanie Plageman <[email protected]>
Discussion: https://postgr.es/m/CAAKRu_acc6iL4M3hvOTeztf_ZPpsB3Pqio5aVHgZ5q=Pi3BZKg@mail.gmail.com