Two of the members of rconn were left uninitialized. When
dblink_open() is called without an outer transaction it
handles the initialization for us, but with an outer
transaction it does not. Arrange for initialization
in all cases. Backpatch to all supported versions.

Reported-by: Alexander Lakhin
Discussion: https://www.postgresql.org/message-id/flat/9bd0744f-5f04-c778-c5b3-809efe9c30c7%40joeconway.com#c545909a41664991aca60c4d70a10ce7

The repeat() function loops for potentially a long time without
ever checking for interrupts. This prevents, for example, a query
cancel from interrupting until the work is all done. Fix by
inserting a CHECK_FOR_INTERRUPTS() into the loop.

Backpatch to all supported versions.

Discussion: https://www.postgresql.org/message-id/flat/8692553c-7fe8-17d9-cbc1-7cddb758f4c6%40joeconway.com

ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE was used in an ereport with the
same message but different errdetail a few lines earlier, so use that
here as well.

Backpatch-through: 11

The same comment was copied to a few different places, with the same typo.
Backpatch down to v11, where this typo was introduced.

segment_open and segment_close were mentioned with incorrect names.

Discussion: https://postgr.es/m/20200525234944.GA1573@paquier.xyz

The default unit for max_slot_wal_keep_size is megabytes.  While on it,
also change temp_file_limit to use a more consistent wording.

Reported-by: Jeff Janes, Fujii Masao
Author: Kyotaro Horiguchi
Discussion: https://postgr.es/m/CAMkU=1wWZhhjpwRFKJ9waQGxxROeC0P6UqPvb90fAaGz7dhoHA@mail.gmail.com

This is not handled uniformly throughout the code, but at least nearby
code can be consistent.

Disk-based HashAgg relies on writing to multiple tapes
concurrently. Avoid fragmentation of the tapes' blocks by
preallocating many blocks for a tape at once. No file operations are
performed during preallocation; only the block numbers are reserved.

Reviewed-by: Tomas Vondra
Discussion: https://postgr.es/m/20200519151202.u2p2gpiawoaznsv2%40development

Make the wording of new libpq messages more similar to existing
messages in the backend.

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