This was done for all scanners in
42116736 but not added to the new one.

Reported-by: Daniel Gustafsson

Discussion: https://postgr.es/m/54F7560D-498A-4E51-BAA4-17D4AAB2AA57@yesql.se

Backpatch-through: master

These were missed when these were added to pg_hba.conf in PG 12;
updates docs and pg_hba.conf.sample.

Reported-by: Arthur Nascimento

Bug: 16380

Discussion: https://postgr.es/m/20200421182736.GG19613@momjian.us

Backpatch-through: 12

The stmt_len changes do not affect behavior.  LimitPath has no other
support functions, so that part changes only debugging output.

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

pg_shmem_allocations was in the wrong position with pg_stats.

Author: Ian Barwick
Discussion: https://postgr.es/m/de7279d4-7ea0-037f-d7d2-1161682339db@2ndquadrant.com

The following commands have been missing calls to object access hooks
InvokeObjectPost{Create|Alter}Hook normally applied to all commands:
- ALTER RULE RENAME TO
- ALTER USER MAPPING
- CREATE ACCESS METHOD
- CREATE STATISTICS

Thanks also to Robert Haas for the discussion.

Author: Mark Dilger
Reviewed-by: Álvaro Herrera, Michael Paquier
Discussion: https://postgr.es/m/435CD295-F409-44E0-91EC-DF32C7AFCD76@enterprisedb.com

They were introduced in 898e5e32; backpatch to 12.

Explain that the followings are tracked only when track_io_timing GUC
is enabled.

- blk_read_time and blk_write_time in pg_stat_database
- time spent reading and writing data file blocks in EXPLAIN output
   with BUFFERS option

Whther track_io_timing is enabled affects also blk_read_time and
blk_write_time in pg_stat_statements, but which was already documented.

Author: Atsushi Torikoshi
Reviewed-by: Fujii Masao
Discussion: https://postgr.es/m/CACZ0uYHo_NwbxpLH76OGF-O=13tkR0ZM0zeyGEhZ+JEXZVRyCA@mail.gmail.com

Probably copied from nearby calls where it is necessary.  But this one
also casts away constness, so it was doubly annoying.

The previous indentation of optimizer functions was unclear; adjust the
indentation dashes so that a deeper level of indentation indicates that
the outer optimizer function calls the inner one.

Author: Richard Guo, with additional change by me
Reviewed-by: Kyotaro Horiguchi
Discussion: https://postgr.es/m/CAMbWs4-U-ogzpchGsP2BBMufCss1hktm%2B%2BeTJK_dUC196pw0cQ%40mail.gmail.com

Reported-by: Erwin Brandstetter

Discussion: https://postgr.es/m/CAGHENJ4X626ZfYhondXSP4sQgC5zDtsp_LNg1QaD+U7vfgYXQQ@mail.gmail.com

Backpatch-through: head

Reported-by: Erwin Brandstetter

Discussion: https://postgr.es/m/CAGHENJ4X626ZfYhondXSP4sQgC5zDtsp_LNg1QaD+U7vfgYXQQ@mail.gmail.com

Backpatch-through: head

Reported-by: yigong hu

Discussion: https://postgr.es/m/CAOxFffcourucFqSk+tZA13ErS3XRYkDy6EeaPff4AvHGiEEuug@mail.gmail.com

Backpatch-through: 9.5

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

Backpatch-through: 9.5

The B-Tree index deduplication strategy used during CREATE INDEX and
REINDEX differs from the lazy strategy used by retail inserts.  Make
that clear by adding a new paragraph to the B-Tree implementation
section of the documentation.

In passing, do some copy-editing of nearby deduplication documentation.

Since 74a308cf, any security-sensitive information gets cleared from
memory this way.  This was forgotten in 4dc63552.

Author: Daniel Gustafsson
Reviewed-by: Peter Eisentraut, Michael Paquier
Discussion: https://postgr.es/m/935443BA-D42E-4CE0-B181-1AD79E6DD45A@yesql.se

When installing binaries and libraries using the MSVC installation
routines, the operation gets done after moving to the root folder, whose
location is detected by checking if "configure" exists two times in a
row.  So, calling the installation script from src/tools/msvc/ with an
extra "configure" file four levels up the root path of the code tree
causes the execution to go further up, leading to a failure in finding
the builds.  This commit fixes the issue by moving to the root folder of
the code tree only once, when necessary.

Author: Arnold Müller
Reviewed-by: Daniel Gustafsson
Discussion: https://postgr.es/m/16343-f638f67e7e52b86c@postgresql.org
Backpatch-through: 9.5

This doc update was missed in 898e5e32.  Backpatch to 12.

Pointed out by Pavel Luzanov
Discussion: https://postgr.es/m/642e9fbc-b832-698b-9a8f-d626afd7014d@postgrespro.ru

The description missed a comma and lacked an explanation of what happens
with REPLICA IDENTITY USING INDEX when the dependent index is dropped.

Author: Marina Polyakova
Reviewed-by: Daniel Gustafsson, Michael Paquier
Discussion: https://postgr.es/m/ad1a0badc32658b1bbb07aa312346a1d@postgrespro.ru
Backpatch-through: 9.5

Oversight in 2c8dd05d, where the view's column has been renamed.

Reported-by: Fujii Masao
Discussion: https://postgr.es/m/c049ffcf-d2fe-90f7-c8ba-0741035aa6a7@oss.nttdata.com

This should be plain old ColId.  Making it so makes the grammar less
complicated, and makes the compiled tables a kilobyte or so smaller
(likely because they don't have to deal with a keyword classification
that's not used anyplace else).

Commit 624686ab added an assertion that verified that _bt_search
successfully relocated the leaf page undergoing deletion.  Page deletion
cannot deal with the case where the descent stack is to the right of the
page, so this seemed critical (deletion can only handle the case where
the descent stack is to the left of the leaf/target page).  However, the
assertion went a bit too far.

Since only a buffer pin is held on the leaf page throughout the call to
_bt_search, nothing guarantees that it can't have split during this
small window.  And if does actually split, _bt_search may end up
"relocating" a page to the right of the original target leaf page.  This
scenario seems extremely unlikely, but it must still be considered.
Remove the assertion, and document how we cope in this scenario.

FETCH FIRST .. ONLY implements this correctly, but we missed to include
it for FETCH FIRST .. WITH TIES in commit 357889eb.

Author: Vik Fearing
Discussion: https://postgr.es/m/6aa690ef-551d-e24f-2690-c38c2442947c@postgresfriends.org

g_comment_start and g_comment_end have been unused since commit
30ab5bd4.

Daniel Gustafsson

Discussion: https://postgr.es/m/2CA1BA9F-CDF9-41BE-96A1-2EFD2A3EA6CA@yesql.se

Reported-by: Daniel Gustafsson

Discussion: https://postgr.es/m/0A9D816E-F49C-470B-A23F-8B4AF999382B@yesql.se

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 031ca65d7825c3e539a3e62ea9d6630af12e6b6b

Author: Daniel Gustafsson

Reported-by: Sawada Masahiko
Author: Sawada Masahiko
Reviewed-by: Amit Kapila
Backpatch-through: 9.5
Discussion: https://postgr.es/m/CA+fd4k4Ws7M7YQ8PqSym5WB1y75dZeBTd1sZJUQdfe0KJQ-iSA@mail.gmail.com

 * Rename column "Opfamily Name" to "Operator family" for uniformity.
 * Rename column alias from "t1" to "t".

Make number of translate_columns elements match the number of output columns.
The only "true" value, which was previously specified, seems to be intended
for opfamily operator "purpose" column.  But that column has already translated
values substituted.  So, all elements in translate_columns[] should be "false".

This commit changes ORDER BY clause for \dAo and \dAp psql commands in
the following way.
 * Operators for the same types are grouped together.
 * Same-class operators and procedures are listed before cross-class operators
   and procedures.

Modification of ORDER BY clause for \dAp required removing DISTINCT clause,
which doesn't seem to affect anything.

Discussion: https://postgr.es/m/20200511210856.GA18368%40alvherre.pgsql
Author: Alvaro Herrera revised by me
Reviewed-by: Alexander Korotkov, Nikita Glukhov

Author: Erik Rijkers <er@xs4all.nl>
Discussion: https://postgr.es/m/508f2fb1764c3bd518ee96a4f2247d6f@xs4all.nl

Synchronize the event names for parallel hash join waits with other
event names, by getting rid of the slashes and dropping "-ing"
suffixes.  Rename ClogGroupUpdate to XactGroupUpdate, to match the
new SLRU name.  Move the ProcSignalBarrier event to the IPC category;
it doesn't belong under IO.

Also a bit more wordsmithing in the wait event documentation tables.

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

d140f2f3 has renamed receivedUpto to flushedUpto, and has added
writtenUpto to the WAL receiver's shared memory information, but
pg_stat_wal_receiver was not consistent with that.  This commit renames
received_lsn to flushed_lsn, and adds a new column called written_lsn.

Bump catalog version.

Author: Michael Paquier
Reviewed-by: Álvaro Herrera
Discussion: https://postgr.es/m/20200515090817.GA212736@paquier.xyz

libpq's exports.txt was overlooked in commit 36d10876, which the
buildfarm is quite unhappy about.

Also, I'd gathered that the plan included renaming PQgetSSLKeyPassHook
to PQgetSSLKeyPassHook_OpenSSL, but that didn't happen in the patch
as committed.  I'm taking it on my own authority to do so now, since
the window before beta1 is closing fast.

4dc63552 provided a way for libraries and clients to modify how libpq
handles client certificate passphrases, by installing a hook. However,
these routines are quite specific to how OpenSSL works, so it's
misleading and not future-proof to have these names not refer to OpenSSL.
Change all the names to add "_OpenSSL" after "Hook", and fix the docs
accordingly.

Author: Daniel Gustafsson

Discussion: https://postgr.es/m/981DE552-E399-45C2-9F60-3F0E3770CC61@yesql.se

Reported privately by Justin Pryzby