Prevent setting a column as identity if its not-null constraint is invalid

We don't allow null values to appear in identity-generated columns in
other ways, so we shouldn't let unvalidated not-null constraints do it
either.  Oversight in commit a379061a22a8.

Author: jian he <[email protected]>
Backpatch-through: 18
Discussion: https://postgr.es/m/CACJufxGQM_+vZoYJMaRoZfNyV=L2jxosjv_0TLAScbuLJXWRfQ@mail.gmail.com

Remove WaitPMResult enum in pg_createsubscriber

A simple boolean suffices.  This is cosmetic, so no backpatch.

Author: Álvaro Herrera <[email protected]>
Discussion: https://postgr.es/m/202510311750[email protected]

Add wal_fpi_bytes to VACUUM and ANALYZE logs

The new wal_fpi_bytes counter calculates the total amount of full page
images inserted in WAL records, in bytes.  This commit adds this
information to VACUUM and ANALYZE logs alongside the existing counters,
building upon f9a09aa29520.

Author: Shinya Kato <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>
Discussion: https://postgr.es/m/[email protected]

Sort guc_parameters.dat alphabetically by name

The order in this list was previously pretty random and had grown
organically over time.  This made it unnecessarily cumbersome to
maintain these lists, as there was no clear guidelines about where to
put new entries.  Also, after the merger of the type-specific GUC
structs, the list still reflected the previous type-specific
super-order.

By using alphabetical order, the place for new entries becomes clear,
and often related entries will be listed close together.

This patch reorders the existing entries in guc_parameters.dat, and it
also augments the generation script to error if an entry is found at
the wrong place.

Note: The order is actually checked after lower-casing, to handle the
likes of "DateStyle".

Reviewed-by: John Naylor <[email protected]>
Reviewed-by: Álvaro Herrera <[email protected]>
Reviewed-by: Heikki Linnakangas <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/8fdfb91e-60fb-44fa-8df6-f5dea47353c9@eisentraut.org

Change "long" numGroups fields to be Cardinality (i.e., double).

We've been nibbling away at removing uses of "long" for a long time,
since its width is platform-dependent.  Here's one more: change the
remaining "long" fields in Plan nodes to Cardinality, since the three
surviving examples all represent group-count estimates.  The upstream
planner code was converted to Cardinality some time ago; for example
the corresponding fields in Path nodes are type Cardinality, as are
the arguments of the make_foo_path functions.  Downstream in the
executor, it turns out that these all feed to the table-size argument
of BuildTupleHashTable.  Change that to "double" as well, and fix it
so that it safely clamps out-of-range values to the uint32 limit of
simplehash.h, as was not being done before.

Essentially, this is removing all the artificial datatype-dependent
limitations on these values from upstream processing, and applying
just one clamp at the moment where we're forced to do so by the
datatype choices of simplehash.h.

Also, remove BuildTupleHashTable's misguided attempt to enforce
work_mem/hash_mem_limit.  It doesn't have enough information
(particularly not the expected tuple width) to do that accurately,
and it has no real business second-guessing the caller's choice.
For all these plan types, it's really the planner's responsibility
to not choose a hashed implementation if the hashtable is expected
to exceed hash_mem_limit.  The previous patch improved the
accuracy of those estimates, and even if BuildTupleHashTable had
more information it should arrive at the same conclusions.

Reported-by: Jeff Janes <[email protected]>
Author: Tom Lane <[email protected]>
Reviewed-by: David Rowley <[email protected]>
Discussion: https://postgr.es/m/CAMkU=1zia0JfW_QR8L5xA2vpa0oqVuiapm78h=WpNsHH13_9uw@mail.gmail.com

Improve planner's estimates of tuple hash table sizes.

For several types of plan nodes that use TupleHashTables, the
planner estimated the expected size of the table as basically
numEntries * (MAXALIGN(dataWidth) + MAXALIGN(SizeofHeapTupleHeader)).
This is pretty far off, especially for small data widths, because
it doesn't account for the overhead of the simplehash.h hash table
nor for any per-tuple "additional space" the plan node may request.
Jeff Janes noted a case where the estimate was off by about a factor
of three, even though the obvious hazards such as inaccurate estimates
of numEntries or dataWidth didn't apply.

To improve matters, create functions provided by the relevant executor
modules that can estimate the required sizes with reasonable accuracy.
(We're still not accounting for effects like allocator padding, but
this at least gets the first-order effects correct.)

I added functions that can estimate the tuple table sizes for
nodeSetOp and nodeSubplan; these rely on an estimator for
TupleHashTables in general, and that in turn relies on one for
simplehash.h hash tables.  That feels like kind of a lot of mechanism,
but if we take any short-cuts we're violating modularity boundaries.

The other places that use TupleHashTables are nodeAgg, which took
pains to get its numbers right already, and nodeRecursiveunion.
I did not try to improve the situation for nodeRecursiveunion because
there's nothing to improve: we are not making an estimate of the hash
table size, and it wouldn't help us to do so because we have no
non-hashed alternative implementation.  On top of that, our estimate
of the number of entries to be hashed in that module is so suspect
that we'd likely often choose the wrong implementation if we did have
two ways to do it.

Reported-by: Jeff Janes <[email protected]>
Author: Tom Lane <[email protected]>
Reviewed-by: David Rowley <[email protected]>
Discussion: https://postgr.es/m/CAMkU=1zia0JfW_QR8L5xA2vpa0oqVuiapm78h=WpNsHH13_9uw@mail.gmail.com

Document nbtree row comparison design.

Add comments explaining when and where it is safe for nbtree to treat
row compare keys as if they were simple scalar inequality keys on the
row's most significant column.  This is particularly important within
_bt_advance_array_keys, which deals with required inequality keys in a
general and uniform way, without any special handling for row compares.

Also spell out the implications of _bt_check_rowcompare's approach of
_conditionally_ evaluating lower-order row compare subkeys, particularly
when one of its lower-order subkeys might see NULL index tuple values
(these may or may not affect whether the qual as a whole is satisfied).
The behavior in this area isn't particularly intuitive, so these issues
seem worth going into.

In passing, add a few more defensive/documenting row comparison related
assertions to _bt_first and _bt_check_rowcompare.

Follow-up to commits bd3f59fd and ec986020.

Author: Peter Geoghegan <[email protected]>
Reviewed-By: Victor Yegorov <[email protected]>
Reviewed-By: Chao Li <[email protected]>
Discussion: https://postgr.es/m/CAH2-Wznwkak_K7pcAdv9uH8ZfNo8QO7+tHXOaCUddMeTfaCCFw@mail.gmail.com
Backpatch-through: 18

Remove obsolete nbtree equality key comments.

_bt_first reliably uses the same equality key (on each index column) for
initial positioning purposes as the one that _bt_checkkeys can use to
end the scan following commit f09816a0.  _bt_first no longer applies its
own independent rules to determine which initial positioning key to use
on each column (for equality and inequality keys alike).  Preprocessing
is now fully in control of determining which keys start and end each
scan, ensuring that _bt_first and _bt_checkkeys have symmetric behavior.

Remove obsolete comments that described why _bt_first was expected to
use at least one of the available required equality keys for initial
positioning purposes.  The rules in this area are now maximally strict
and uniform, so there's no reason to draw attention to equality keys.
Any column with a required equality key cannot have a redundant required
inequality key (nor can it have a redundant required equality key).

Oversight in commit f09816a0, which removed similar comments from
_bt_first, but missed these comments.

Author: Peter Geoghegan <[email protected]>
Backpatch-through: 18

Avoid mixing void and integer in a conditional expression.

The C standard says that the second and third arguments of a
conditional operator shall be both void type or both not-void
type.  The Windows version of INTERRUPTS_PENDING_CONDITION()
got this wrong.  It's pretty harmless because the result of
the operator is ignored anyway, but apparently recent versions
of MSVC have started issuing a warning about it.  Silence the
warning by casting the dummy zero to void.

Reported-by: Christian Ullrich <[email protected]>
Author: Bryan Green <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/cc4ef8db-f8dc-4347-8a22-e7ebf44c0308@chrullrich.net
Backpatch-through: 13

Remove unused variable in recovery/t/006_logical_decoding.pl.

Author: Daniil Davydov <[email protected]>
Reviewed-by: Daniel Gustafsson <[email protected]>
Discussion: https://postgr.es/m/CAJDiXggmZWew8+SY_9o0atpmaJmPTL25wdz07MrDoqCkp4D1ug@mail.gmail.com

Fix contrib/ltree's subpath() with negative offset.

subpath(ltree,offset,len) now correctly errors when given an offset
less than -n, where n is the number of labels in the given ltree.
There was a duplicate block of code that allowed an offset as low
as -2n.  The documentation says no such thing, so this must have
been a copy-and-paste error in the original ltree patch.

While here, avoid redundant calculation of "end" and write
LTREE_MAX_LEVELS rather than its hard-coded value.

Author: Marcus Gartner <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/CAAUGV_SvBO9gWYbaejb9nhe-mS9FkNP4QADNTdM3wdRhvLobwA@mail.gmail.com

pg_createsubscriber: reword dry-run log messages

The original messages were confusing in dry-run mode in that they state
that something is being done, when in reality it isn't.  Use alternative
wording in that case, to make the distinction clear.

Author: Peter Smith <[email protected]>
Reviewed-by: Chao Li <[email protected]>
Reviewed-by: Euler Taveira <[email protected]>
Backpatch-through: 18
Discussion: https://postgr.es/m/CAHut+PsvQJQnQO0KT0S2oegenkvJ8FUuY-QS5syyqmT24R2xFQ@mail.gmail.com

pg_createsubscriber: Fix error complaining about the wrong thing

The code updates the system identifier, then runs pg_walreset; if the
latter fails, it complains about the former, which makes no sense.
Change the error message to complain about the right thing.

Noticed while reviewing a patch touching nearby code.

Author: Álvaro Herrera <[email protected]>
Backpatch-through: 17

Mark function arguments of type "Datum *" as "const Datum *" where possible

Several functions in the codebase accept "Datum *" parameters but do
not modify the pointed-to data.  These have been updated to take
"const Datum *" instead, improving type safety and making the
interfaces clearer about their intent.  This change helps the compiler
catch accidental modifications and better documents immutability of
arguments.

Most of "Datum *" parameters have a pairing "bool *isnull" parameter,
they are constified as well.

No functional behavior is changed by this patch.

Author: Chao Li <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/CAEoWx2msfT0knvzUa72ZBwu9LR_RLY4on85w2a9YpE-o2By5HQ@mail.gmail.com

formatting.c cleanup: Change fill_str() return type to void

The return value is not used anywhere.

In passing, add a comment explaining the function's arguments.

Reviewed-by: Chao Li <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/6dd9d208-a3ed-49b5-b03d-8617261da973%40eisentraut.org

formatting.c cleanup: Rename DCH_S_* to DCH_SUFFIX_*

For clarity.  Also rename several related macros and turn them into
inline functions.

Reviewed-by: Chao Li <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/6dd9d208-a3ed-49b5-b03d-8617261da973%40eisentraut.org

formatting.c cleanup: Change several int fields to enums

This makes their purpose more self-documenting.

Reviewed-by: Chao Li <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/6dd9d208-a3ed-49b5-b03d-8617261da973%40eisentraut.org

formatting.c cleanup: Change TmFromChar.clock field to bool

This makes the purpose clearer and avoids having two extra symbols,
one of which (CLOCK_24_HOUR) was unused.

Reviewed-by: Chao Li <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/6dd9d208-a3ed-49b5-b03d-8617261da973%40eisentraut.org

Add test tracking WAL receiver shutdown for primary_conninfo updates

The test introduced by this commit checks that a reload of
primary_conninfo leads to a WAL receiver restarted, by looking at the
request generated in the server logs.  This is something for what there
was no coverage.

This has come up for a different patch, while discussing a regression
where a WAL receiver should not be stopped while waiting for a new
position to stream, like at the end of a timeline.  In the case of the
other patch, we want to check that this log entry is not generated, but
if the error message is reworded the test would become silently broken.
The test of this commit ensures that we at least keep track the log
message format, for a supported scenario.

Extracted from a larger patch by the same author.

Author: Xuneng Zhou <[email protected]>
Discussion: https://postgr.es/m/[email protected]

doc:  rewrite random_page_cost description

This removes some of the specifics of how the default was set, and adds
a mention of latency as a reason the value is lower than the storage
hardware might suggest.  It still mentions caching.

Discussion: https://postgr.es/m/CAKAnmmK_nSPYr53LobUwQD59a-8U9GEC3XGJ43oaTYJq5nAOkw@mail.gmail.com

Backpatch-through: 13

ci: macos: Upgrade to Sequoia

Author: Nazir Bilal Yavuz <[email protected]>
Discussion: https://postgr.es/m/CAN55FZ3kO4vLq56PWrfJ7Fw6Wz8DhEN9j9GX3aScx%2BWOirtK-g%40mail.gmail.com
Backpatch: 15-, where CI support was added

ci: Fix Windows and MinGW task names

They use Windows Server 2022, not 2019.

Author: Nazir Bilal Yavuz <[email protected]>
Discussion: https://postgr.es/m/flat/CAN55FZ1OsaM+852BMQDJ+Kgfg+07knJ6dM3PjbGbtYaK4qwfqA@mail.gmail.com

Use BumpContext contexts in TupleHashTables, and do some code cleanup.

For all extant uses of TupleHashTables, execGrouping.c itself does
nothing with the "tablecxt" except to allocate new hash entries in it,
and the callers do nothing with it except to reset the whole context.
So this is an ideal use-case for a BumpContext, and the hash tables
are frequently big enough for the savings to be significant.

(Commit cc721c459 already taught nodeAgg.c this idea, but neglected
the other callers of BuildTupleHashTable.)

While at it, let's clean up some ill-advised leftovers from rebasing
TupleHashTables on simplehash.h:

* Many comments and variable names were based on the idea that the
tablecxt holds the whole TupleHashTable, whereas now it only holds the
hashed tuples (plus any caller-defined "additional storage").  Rename
to names like tuplescxt and tuplesContext, and adjust the comments.
Also adjust the memory context names to be like "<Foo> hashed tuples".

* Make ResetTupleHashTable() reset the tuplescxt rather than relying
on the caller to do so; that was fairly bizarre and seems like a
recipe for leaks.  This is less efficient in the case where nodeAgg.c
uses the same tuplescxt for several different hashtables, but only
microscopically so because mcxt.c will short-circuit the extra resets
via its isReset flag.  I judge the extra safety and intellectual
cleanliness well worth those few cycles.

* Remove the long-obsolete "allow_jit" check added by ac88807f9;
instead, just Assert that metacxt and tuplescxt are different.
We need that anyway for this definition of ResetTupleHashTable() to
be safe.

There is a side issue of the extent to which this change invalidates
the planner's estimates of hashtable memory consumption.  However,
those estimates are already pretty bad, so improving them seems like
it can be a separate project.  This change is useful to do first to
establish consistent executor behavior that the planner can expect.

A loose end not addressed here is that the "entrysize" calculation
in BuildTupleHashTable seems wrong: "sizeof(TupleHashEntryData) +
additionalsize" corresponds neither to the size of the simplehash
entries nor to the total space needed per tuple.  It's questionable
why BuildTupleHashTable is second-guessing its caller's nbuckets
choice at all, since the original source of the number should have had
more information.  But that all seems wrapped up with the planner's
estimation logic, so let's leave it for the planned followup patch.

Reported-by: Jeff Janes <[email protected]>
Reported-by: David Rowley <[email protected]>
Author: Tom Lane <[email protected]>
Reviewed-by: David Rowley <[email protected]>
Discussion: https://postgr.es/m/CAMkU=1zia0JfW_QR8L5xA2vpa0oqVuiapm78h=WpNsHH13_9uw@mail.gmail.com
Discussion: https://postgr.es/m/2268409.1761512111@sss.pgh.pa.us

Mark ItemPointer arguments as const throughout

This is a follow up 991295f.  I searched over src/ and made all
ItemPointer arguments as const as much as possible.

Note: We cut out from the original patch the pieces that would have
created incompatibilities in the index or table AM APIs.  Those could
be considered separately.

Author: Chao Li <[email protected]>
Discussion: https://www.postgresql.org/message-id/CAEoWx2nBaypg16Z5ciHuKw66pk850RFWw9ACS2DqqJ_AkKeRsw%40mail.gmail.com

Simplify coding in ProcessQuery

The original is pretty baroque for no apparent reason; arguably, commit
2f9661311b83 should have done this.  Noted while reviewing related code
for bug #18984.  This is cosmetic (though I'm surprised that my compiler
generates shorter assembly this way), so no backpatch.

Discussion: https://postgr.es/m/18984-0f4778a6599ac3ae@postgresql.org

Fix some confusing uses of const

There are a few places where we have

    typedef struct FooData { ... } FooData;
    typedef FooData *Foo;

and then function declarations with

    bar(const Foo x)

which isn't incorrect but probably meant

    bar(const FooData *x)

meaning that the thing x points to is immutable, not x itself.

This patch makes those changes where appropriate.  In one
case (execGrouping.c), the thing being pointed to was not immutable,
so in that case remove the const altogether, to avoid further
confusion.

Co-authored-by: Chao Li <[email protected]>
Discussion: https://www.postgresql.org/message-id/CAEoWx2m2E0xE8Kvbkv31ULh_E%2B5zph-WA_bEdv3UR9CLhw%2B3vg%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAEoWx2kTDz%3Db6T2xHX78vy_B_osDeCC5dcTCi9eG0vXHp5QpdQ%40mail.gmail.com

docs: Link to the correct protocol version inspection function

The docs for max_protocol_version suggested PQprotocolVersion()
instead of PQfullProtocolVersion() to find out the exact protocol
version.  Since PQprotocolVersion() only returns the major protocol
version, that is bad advice.

Author: Jelte Fennema-Nio <[email protected]>
Reviewed-by: Shinya Kato <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/CAGECzQSKFxQsYAgr11PhdOr-RtPZEdAXZnHx6U3avLuk3xQaTQ%40mail.gmail.com

const-qualify ItemPointer comparison functions

Add const qualifiers to ItemPointerEquals() and ItemPointerCompare().
This will allow further changes up the stack.  It also complements
commit aeb767ca0b0, as we now have all of itemptr.h appropriately
const-qualified.

Author: Chao Li <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/CAEoWx2nBaypg16Z5ciHuKw66pk850RFWw9ACS2DqqJ_AkKeRsw@mail.gmail.com

formatting.c cleanup: Improve formatting of some struct declarations

This makes future editing easier.

Reviewed-by: Chao Li <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/6dd9d208-a3ed-49b5-b03d-8617261da973%40eisentraut.org

formatting.c cleanup: Remove unnecessary zeroize macros

Replace with initializer or memset().

Reviewed-by: Chao Li <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/6dd9d208-a3ed-49b5-b03d-8617261da973%40eisentraut.org

formatting.c cleanup: Remove unnecessary extra line breaks in error message literals

Reviewed-by: Chao Li <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/6dd9d208-a3ed-49b5-b03d-8617261da973%40eisentraut.org

Expose wal_fpi_bytes in EXPLAIN (WAL)

The new wal_fpi_bytes counter calculates the total amount of full page
images inserted in WAL records, in bytes.  This commit exposes this
information in EXPLAIN (ANALYZE, WAL) alongside the existing counters,
for both the text and JSON/YAML outputs, building upon f9a09aa29520.

Author: Shinya Kato <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>
Discusssion: https://postgr.es/m/CAOzEurQtZEAfg6P0kU3Wa-f9BWQOi0RzJEMPN56wNTOmJLmfaQ@mail.gmail.com

Fix regression with slot invalidation checks

This commit reverts 818fefd8fd4, that has been introduced to address a
an instability in some of the TAP tests due to the presence of random
standby snapshot WAL records, when slots are invalidated by
InvalidatePossiblyObsoleteSlot().

Anyway, this commit had also the consequence of introducing a behavior
regression.  After 818fefd8fd4, the code may determine that a slot needs
to be invalidated while it may not require one: the slot may have moved
from a conflicting state to a non-conflicting state between the moment
when the mutex is released and the moment when we recheck the slot, in
InvalidatePossiblyObsoleteSlot().  Hence, the invalidations may be more
aggressive than they actually have to.

105b2cb3361 has tackled the test instability in a way that should be
hopefully sufficient for the buildfarm, even for slow members:
- In v18, the test relies on an injection point that bypasses the
creation of the random records generated for standby snapshots,
eliminating the random factor that impacted the test.  This option was
not available when 818fefd8fd4 was discussed.
- In v16 and v17, the problem was bypassed by disallowing a slot to
become active in some of the scenarios tested.

While on it, this commit adds a comment to document that it is fine for
a recheck to use xmin and LSN values stored in the slot, without storing
and reusing them across multiple checks.

Reported-by: "suyu.cmj" <[email protected]>
Author: Bertrand Drouvot <[email protected]>
Reviewed-by: Masahiko Sawada <[email protected]>
Reviewed-by: Amit Kapila <[email protected]>
Discussion: https://postgr.es/m/f492465f-657e-49af-8317-987460cb68b0[email protected]
Backpatch-through: 16

Disable parallel plans for RIGHT_SEMI joins

RIGHT_SEMI joins rely on the HEAP_TUPLE_HAS_MATCH flag to guarantee
that only the first match for each inner tuple is considered.
However, in a parallel hash join, the inner relation is stored in a
shared global hash table that can be probed by multiple workers
concurrently.  This allows different workers to inspect and set the
match flags of the same inner tuples at the same time.

If two workers probe the same inner tuple concurrently, both may see
the match flag as unset and emit the same tuple, leading to duplicate
output rows and violating RIGHT_SEMI join semantics.

For now, we disable parallel plans for RIGHT_SEMI joins.  In the long
term, it may be possible to support parallel execution by performing
atomic operations on the match flag, for example using a CAS or
similar mechanism.

Backpatch to v18, where RIGHT_SEMI join was introduced.

Bug: #19094
Reported-by: Lori Corbani <[email protected]>
Diagnosed-by: Tom Lane <[email protected]>
Author: Richard Guo <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/19094-6ed410eb5b256abd@postgresql.org
Backpatch-through: 18

Fix bogus use of "long" in AllocSetCheck()

Because long is 32-bit on 64-bit Windows, it isn't a good datatype to
store the difference between 2 pointers.  The under-sized type could
overflow and lead to scary warnings in MEMORY_CONTEXT_CHECKING builds,
such as:

WARNING:  problem in alloc set ExecutorState: bad single-chunk %p in block %p

However, the problem lies only in the code running the check, not from
an actual memory accounting bug.

Fix by using "Size" instead of "long".  This means using an unsigned
type rather than the previous signed type.  If the block's freeptr was
corrupted, we'd still catch that if the unsigned type wrapped.  Unsigned
allows us to avoid further needless complexities around comparing signed
and unsigned types.

Author: David Rowley <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Backpatch-through: 13
Discussion: https://postgr.es/m/CAApHDvo-RmiT4s33J=aC9C_-wPZjOXQ232V-EZFgKftSsNRi4w@mail.gmail.com

Use C11 char16_t and char32_t for Unicode code points.

Reviewed-by: Tatsuo Ishii <[email protected]>
Reviewed-by: Thomas Munro <[email protected]>
Reviewed-by: Peter Eisentraut <[email protected]>
Discussion: https://postgr.es/m/bedcc93d06203dfd89815b10f815ca2de8626e85.camel%40j-davis.com

pg_stat_statements: Fix handling of duplicate constant locations

Two or more constants can have the same location.  We handled this
correctly for non squashed constants, but failed to do it if squashed
(resulting in out-of-bounds memory access), because the code structure
became broken by commit 0f65f3eec478: we failed to update 'last_loc'
correctly when skipping these squashed constants.

The simplest fix seems to be to get rid of 'last_loc' altogether -- in
hindsight, it's quite pointless.  Also, when ignoring a constant because
of this, make sure to fulfill fill_in_constant_lengths's duty of setting
its length to -1.

Lastly, we can use == instead of <= because the locations have been
sorted beforehand, so the < case cannot arise.

Co-authored-by: Sami Imseih <[email protected]>
Co-authored-by: Dmitry Dolgov <[email protected]>
Reported-by: Konstantin Knizhnik <[email protected]>
Backpatch-through: 18
Discussion: https://www.postgresql.org/message-id/2b91e358-0d99-43f7-be44-d2d4dbce37b3%40garret.ru

CheckNNConstraintFetch: Fill all of ConstrCheck in a single pass

Previously, we'd fill all fields except ccbin, and only later obtain and
detoast ccbin, with hypothetical failures being possible.  If ccbin is
null (rare catalog corruption I have never witnessed) or its a corrupted
toast entry, we leak a tiny bit of memory in CacheMemoryContext from
having strdup'd the constraint name.  Repair these by only attempting to
fill the struct once ccbin has been detoasted.

Author: Ranier Vilela <[email protected]>
Discussion: https://postgr.es/m/CAEudQAr=i3_Z4GvmediX900+sSySTeMkvuytYShhQqEwoGyvhA@mail.gmail.com

Reorganize GUC structs

Instead of having five separate GUC structs, one for each type, with
the generic part contained in each of them, flip it around and have
one common struct, with the type-specific part has a subfield.

The very original GUC design had type-specific structs and
type-specific lists, and the membership in one of the lists defined
the type.  But now the structs themselves know the type (from the
.vartype field), and they are all loaded into a common hash table at
run time, and so this original separation no longer makes sense.  It
creates a bunch of inconsistencies in the code about whether the
type-specific or the generic struct is the primary struct, and a lot
of casting in between, which makes certain assumptions about the
struct layouts.

After the change, all these casts are gone and all the data is
accessed via normal field references.  Also, various code is
simplified because only one kind of struct needs to be processed.

Reviewed-by: Chao Li <[email protected]>
Reviewed-by: Heikki Linnakangas <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/8fdfb91e-60fb-44fa-8df6-f5dea47353c9@eisentraut.org

formatting.c cleanup: Remove unnecessary extra parentheses

Reviewed-by: Chao Li <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/6dd9d208-a3ed-49b5-b03d-8617261da973%40eisentraut.org

formatting.c cleanup: Use array syntax instead of pointer arithmetic

for easier readability

Reviewed-by: Chao Li <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/6dd9d208-a3ed-49b5-b03d-8617261da973%40eisentraut.org

formatting.c cleanup: Add some const pointer qualifiers

Co-authored-by: Chao Li <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/6dd9d208-a3ed-49b5-b03d-8617261da973%40eisentraut.org

formatting.c cleanup: Use size_t for string length variables and arguments

Reviewed-by: Chao Li <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/6dd9d208-a3ed-49b5-b03d-8617261da973%40eisentraut.org

Replace pg_restrict by standard restrict

MSVC in C11 mode supports the standard restrict qualifier, so we don't
need the workaround naming pg_restrict anymore.

Even though restrict is in C99 and should be supported by all
supported compilers, we keep the configure test and the hardcoded
redirection to __restrict, because that will also work in C++ in all
supported compilers.  (restrict is not part of the C++ standard.)

For backward compatibility for extensions, we keep a #define of
pg_restrict around, but our own code doesn't use it anymore.

Reviewed-by: Tom Lane <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/0e3d8644-c01d-4374-86ea-9f0a987981f0%40eisentraut.org

Remove obsolete comment

The comment "type prefixes (const, signed, volatile, inline) are
handled in pg_config.h." has been mostly not true for a long time.

Fix correctness issue with computation of FPI size in WAL stats

XLogRecordAssemble() may be called multiple times before inserting a
record in XLogInsertRecord(), and the amount of FPIs generated inside
a record whose insertion is attempted multiple times may vary.

The logic added in f9a09aa29520 touched directly pgWalUsage in
XLogRecordAssemble(), meaning that it could be possible for pgWalUsage
to be incremented multiple times for a single record.  This commit
changes the code to use the same logic as the number of FPIs added to a
record, where XLogRecordAssemble() returns this information and feeds it
to XLogInsertRecord(), updating pgWalUsage only when a record is
inserted.

Reported-by: Shinya Kato <[email protected]>
Discussion: https://postgr.es/m/CAOzEurSiSr+rusd0GzVy8Bt30QwLTK=ugVMnF6=5WhsSrukvvw@mail.gmail.com

Add psql PROMPT variable for search_path.

The new %S substitution shows the current value of search_path.
Note that this only works when connected to Postgres v18 or newer,
since search_path was first marked as GUC_REPORT in commit
28a1121fd9.  On older versions that don't report search_path, %S is
replaced with a question mark.

Suggested-by: Lauri Siltanen <[email protected]>
Author: Florents Tselai <[email protected]>
Reviewed-by: Jelte Fennema-Nio <[email protected]>
Reviewed-by: Jim Jones <[email protected]>
Reviewed-by: Chao Li <[email protected]>
Discussion: https://postgr.es/m/CANsM767JhTKCRagTaq5Lz52fVwLPVkhSpyD1C%2BOrridGv0SO0A%40mail.gmail.com

formatting.c cleanup: Move loop variables definitions into for statement

Reviewed-by: Chao Li <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/6dd9d208-a3ed-49b5-b03d-8617261da973%40eisentraut.org

formatting.c cleanup: Remove dashes in comments

This saves some vertical space and makes the comments style more
consistent with the rest of the code.

Reviewed-by: Chao Li <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/6dd9d208-a3ed-49b5-b03d-8617261da973%40eisentraut.org

Don't error out when dropping constraint if relchecks is already zero

I have never seen this be a problem in practice, but it came up when
purposely corrupting catalog contents to study the fix for a nearby bug:
we'd try to decrement relchecks, but since it's zero we error out and
fail to drop the constraint.  The fix is to downgrade the error to
warning, skip decrementing the counter, and otherwise proceed normally.

Given lack of field complaints, no backpatch.

Author: Álvaro Herrera <[email protected]>
Discussion: https://postgr.es/m/202508291058[email protected]

Move comment about casts from pg_wchar.

Suggested-by: Thomas Munro <[email protected]>
Discussion: https://postgr.es/m/CA+hUKGLXQUYK7Cq5KbLGgTWo7pORs7yhBWO1AEnZt7xTYbLRhg@mail.gmail.com

Check that index can return in get_actual_variable_range()

Some recent changes were made to remove the explicit dependency on
btree indexes in some parts of the code.  One of these changes was
made in commit 9ef1851685b, which allows non-btree indexes to be used
in get_actual_variable_range().  A follow-up commit ee1ae8b99f9 fixes
the cases where an index doesn’t have a sortopfamily as this is a
prerequisite to be used in get_actual_variable_range().

However, it was found that indexes that have amcanorder = true but do
not allow index-only-scans (amcanreturn returns false or is NULL) will
pass all of the conditions, while they should be rejected since
get_actual_variable_range() uses the index-only-scan machinery in
get_actual_variable_endpoint().  Such an index might cause errors like

    ERROR:  no data returned for index-only scan

during query planning.

The fix is to add a check in get_actual_variable_range() to reject
indexes that do not allow index-only scans.

Author: Maxime Schoemans <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/20ED852A-C2D9-41EB-8671-8C8B9D418BE9%40enterprisedb.com

Add wal_fpi_bytes to pg_stat_wal and pg_stat_get_backend_wal()

This new counter, called "wal_fpi_bytes", tracks the total amount in
bytes of full page images (FPIs) generated in WAL.  This data becomes
available globally via pg_stat_wal, and for backend statistics via
pg_stat_get_backend_wal().

Previously, this information could only be retrieved with pg_waldump or
pg_walinspect, which may not be available depending on the environment,
and are expensive to execute.  It offers hints about how much FPIs
impact the WAL generated, which could be a large percentage for some
workloads, as well as the effects of wal_compression or page holes.

Bump catalog version.
Bump PGSTAT_FILE_FORMAT_ID, due to the addition of wal_fpi_bytes in
PgStat_WalCounters.

Author: Shinya Kato <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>
Discussion: https://postgr.es/m/CAOzEurQtZEAfg6P0kU3Wa-f9BWQOi0RzJEMPN56wNTOmJLmfaQ@mail.gmail.com

Add worker type argument to logical replication worker functions.

Extend logicalrep_worker_stop, logicalrep_worker_wakeup, and
logicalrep_worker_find to accept a worker type argument. This change
enables differentiation between logical replication worker types, such as
apply workers and table sync workers. While preserving existing behavior,
it lays the groundwork for upcoming patch to add sequence synchronization
workers.

Author: Vignesh C <[email protected]>
Reviewed-by: shveta malik <[email protected]>
Reviewed-by: Peter Smith <[email protected]>
Reviewed-by: Chao Li <[email protected]>
Reviewed-by: Hayato Kuroda <[email protected]>
Reviewed-by: Amit Kapila <[email protected]>
Discussion: https://postgr.es/m/CAA4eK1LC+KJiAkSrpE_NwvNdidw9F2os7GERUeSxSKv71gXysQ@mail.gmail.com

Simplify newline handling in two TAP tests

Two tests are changed in this commit:
- libpq's 006_service
- ldap's 003_ldap_connection_param_lookup

CRLF translation is already handled by the text mode, so there should be
need for any specific logic.  See also 1c6d4629394d, msys perl being one
case where the translation mattered.

Note: This is first applied on HEAD, and backpatch will follow once the
buildfarm has provided an opinion about this commit.

Author: Jacob Champion <[email protected]>
Co-authored-by: Michael Paquier <[email protected]>
Reviewed-by: Daniel Gustafsson <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 13

Fix a couple of comments.

These were discovered while reviewing Aleksander Alekseev's
proposed changes to pgindent.

Oversights in commits 393e0d2314 and 25a30bbd42.

Discussion: https://postgr.es/m/aP-H6kSsGOxaB21k%40nathan

Add new RLS tests to test policies applied by command type.

The existing RLS tests focus on the outcomes of various testing
scenarios, rather than the exact policies applied. This sometimes
makes it hard to see why a particular result occurred (e.g., which
policy failed), or to construct a test that fails a particular policy
check without an earlier check failing. These new tests issue NOTICE
messages to show the actual policies applied for each command type,
including the different paths through INSERT ... ON CONFLICT and
MERGE, making it easier to verify the expected behaviour.

Author: Dean Rasheed <[email protected]>
Reviewed-by: Viktor Holmberg <[email protected]>
Reviewed-by: Jian He <[email protected]>
Discussion: https://postgr.es/m/CAEZATCWqnfeChjK=n1V_dYZT4rt4mnq+ybf9c0qXDYTVMsy8pg@mail.gmail.com

Add some const qualifications

Add some const qualifications afforded by the previous change that
added a const qualification to PageAddItemExtended().

Reviewed-by: Nathan Bossart <[email protected]>
Reviewed-by: Peter Geoghegan <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/c75cccf5-5709-407b-a36a-2ae6570be766@eisentraut.org

Remove Item type

This type is just char * underneath, it provides no real value, no
type safety, and just makes the code one level more mysterious.  It is
more idiomatic to refer to blobs of memory by a combination of void *
and size_t, so change it to that.

Also, since this type hides the pointerness, we can't apply qualifiers
to what is pointed to, which requires some unconstify nonsense.  This
change allows fixing that.

Extension code that uses the Item type can change its code to use
void * to be backward compatible.

Reviewed-by: Nathan Bossart <[email protected]>
Reviewed-by: Peter Geoghegan <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/c75cccf5-5709-407b-a36a-2ae6570be766@eisentraut.org

Remove meaninglist restrict qualifiers

The use of the restrict qualifier in casts is meaningless, so remove
them.

Reviewed-by: Tom Lane <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/0e3d8644-c01d-4374-86ea-9f0a987981f0%40eisentraut.org

Fix GUC check_hook validation for synchronized_standby_slots.

Previously, the check_hook for synchronized_standby_slots attempted to
validate that each specified slot existed and was physical. However, these
checks were not performed during server startup. As a result, if users
configured non-existent slots before startup, the misconfiguration would
go undetected initially. This could later cause parallel query failures,
as newly launched workers would detect the issue and raise an ERROR.

This patch improves the check_hook by validating the syntax and format of
slot names. Validation of slot existence and type is deferred to the WAL
sender process, aligning with the behavior of the check_hook for
primary_slot_name.

Reported-by: Fabrice Chapuis <[email protected]>
Author: Shlok Kyal <[email protected]>
Reviewed-by: Hayato Kuroda <[email protected]>
Reviewed-by: Amit Kapila <[email protected]>
Reviewed-by: Ashutosh Sharma <[email protected]>
Reviewed-by: Rahila Syed <[email protected]>
Backpatch-through: 17, where it was introduced
Discussion: https://postgr.es/m/CAA5-nLCeO4MQzWipCXH58qf0arruiw0OeUc1+Q=Z=4GM+=v1NQ@mail.gmail.com

Improve test in 009_matviews.pl.

Ensure that the target table on the subscriber exists before executing any
DML intended for replication.

Currently, if the table is missing, the replication logic keeps retrying
until the table is eventually created by the test. Although this behaviour
does not cause test failures, since the table is created after the INSERT
is published and replication eventually succeeds, however, it introduces
unnecessary looping and delays.

Author: Grem Snoort <[email protected]>
Discussion: https://postgr.es/m/CANV9Qw5HD7=Fp4nox2O7DoVctHoabRRVW9Soo4A=QipqW5B=Tg@mail.gmail.com

Comment typo fixes: pg_wchar_t should be pg_wchar.

Reported-by: Thomas Munro <[email protected]>
Discussion: https://postgr.es/m/CA+hUKGJ5Xh0KxLYXDZuPvw1_fHX=yuzb4xxtam1Cr6TPZZ1o+w@mail.gmail.com

Fix incorrect logic for caching ResultRelInfos for triggers

When dealing with ResultRelInfos for partitions, there are cases where
there are mixed requirements for the ri_RootResultRelInfo.  There are
cases when the partition itself requires a NULL ri_RootResultRelInfo and
in the same query, the same partition may require a ResultRelInfo with
its parent set in ri_RootResultRelInfo.  This could cause the column
mapping between the partitioned table and the partition not to be done
which could result in crashes if the column attnums didn't match
exactly.

The fix is simple.  We now check that the ri_RootResultRelInfo matches
what the caller passed to ExecGetTriggerResultRel() and only return a
cached ResultRelInfo when the ri_RootResultRelInfo matches what the
caller wants, otherwise we'll make a new one.

Author: David Rowley <[email protected]>
Author: Amit Langote <[email protected]>
Reported-by: Dmitry Fomin <[email protected]>
Discussion: https://postgr.es/m/7DCE78D7-0520-4207-822B-92F60AEA14B4@gmail.com
Backpatch-through: 15

Guard against division by zero in test_int128 module.

When testing 128/32-bit division in the test_int128 test module, make
sure that we don't attempt to divide by zero.

While at it, use pg_prng_int64() and pg_prng_int32() to generate the
random numbers required for the tests, rather than pg_prng_uint64().
This eliminates the need for any implicit or explicit type casts.

Author: Dean Rasheed <[email protected]>
Reported-by: Andres Freund <[email protected]>
Discussion: https://postgr.es/m/da4wqngd6gwz5s4yf5y5f75xj7gpja62l4dbp6w4j3vs7fcjue@upvolcu4e6o2

pg_rewind: Skip copy of WAL segments generated before point of divergence

This commit makes the way WAL segments are handled from the source to
the target server slightly smarter: the copy of the WAL segments is now
skipped if these have been created before the point where source and
target have diverged (the WAL segment where the point of divergence
exists is still copied), because we know that such segments exist on
both the target and source.  Note that the on-disk size of the WAL
segments on the source and target need to match.  Hence, only the
segments generated after the point of divergence are now copied.  A
segment existing on the source but not the target is copied.

Previously, all the WAL segments were just copied in full.  This change
can make the rewind operation cheaper in some configurations, especially
for setups where some WAL retention causes many segments to remain on
the source server even after the promotion of a standby used as source
to rewind a previous primary.

A TAP test is added to track these new behaviors.  The file map printed
with --debug now includes all the information related to WAL segments,
to be able to track if these are copied or skipped, and the test relies
on the debug output generated.

Author: John Hsu <[email protected]>
Author: Justin Kwan <[email protected]>
Reviewed-by: Robert Haas <[email protected]>
Reviewed-by: Alexander Korotkov <[email protected]>
Reviewed-by: Japin Li <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>
Reviewed-by: Srinath Reddy Sadipiralla <[email protected]>
Discussion: https://postgr.es/m/181b4c6fa9c.b8b725681941212.7547232617810891479@viggy28.dev

psql: Improve tab completion for large objects.

This commit enhances psql's tab completion support for large objects:
- Completes \lo_export <oid> with a file name
- Completes GRANT/REVOKE ... LARGE with OBJECT
- Completes ALTER DEFAULT PRIVILEGES GRANT/REVOKE ... LARGE with OBJECTS

Author: Dagfinn Ilmari Mannsåker <[email protected]>
Co-authored-by: Fujii Masao <[email protected]>
Reviewed-by: Chao Li <[email protected]>
Discussion: https://postgr.es/m/[email protected]

Update expected output for contrib/sepgsql's regression tests.

Commit 65281391a caused some additional error context lines to
appear in the output of one test case.  That's fine, but we missed
updating the expected output.  Do it now.

While here, add some missing test-output subdirectories to
contrib/sepgsql/.gitignore, so that we don't get git warnings
after running the tests.

Author: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/1613232.1761255361@sss.pgh.pa.us
Backpatch-through: 18

doc: Remove mention of Git protocol support

The project Git server hasn't supported cloning with the Git protocol
in a very long time, but the documentation never got the memo. Remove
the mention of using the Git protocol, and while there wrap a mention
of Git in <productname> tags.

Backpatch down to all supported versions.

Author: Daniel Gustafsson <[email protected]>
Reported-by: Gurjeet Singh <[email protected]>
Reviewed-by: Nathan Bossart <[email protected]>
Reviewed-by: Jacob Champion <[email protected]>
Reviewed-by: Gurjeet Singh <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/CABwTF4WMiMb-KT2NRcib5W0C8TQF6URMb+HK9a_=rnZnY8Q42w@mail.gmail.com
Backpatch-through: 13

Avoid memory leak in validation of a PL/Python trigger function.

If we're trying to perform check_function_bodies validation
of a PL/Python trigger function, we create a new PLyProcedure,
but we don't put it into the PLy_procedure_cache hash table.
(Doing so would be useless, since we don't have the relation
OID that is part of the cache key for a trigger function, so
we could not make an entry that would be found by later uses.)
However, we didn't think through what to do instead, with the
result that the PLyProcedure was simply leaked.

It would take a pretty large number of CREATE FUNCTION operations
for this to amount to a serious problem, but it's easy to see the
memory bloat if you do CREATE OR REPLACE FUNCTION in a loop.

To fix, have PLy_procedure_get delete the new PLyProcedure
and return NULL if it's not going to cache the PLyProcedure.
I considered making plpython3_validator do the cleanup instead,
which would be more natural.  But then plpython3_validator would
have to know the rules under which PLy_procedure_get returns a
non-cached PLyProcedure, else it risks deleting something that's
pointed to by a cache entry.  On the whole it seems more robust
to deal with the case inside PLy_procedure_get.

Found by the new version of Coverity (nice catch!).  In the end
I feel this fix is more about satisfying Coverity than about
fixing a real-world problem, so I'm not going to back-patch.

Fix off-by-one Asserts in FreePageBtreeInsertInternal/Leaf.

These two functions expect there to be room to insert another item
in the FreePageBtree's array, but their assertions were too weak
to guarantee that.  This has little practical effect granting that
the callers are not buggy, but it seems to be misleading late-model
Coverity into complaining about possible array overrun.

Author: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/799984.1761150474@sss.pgh.pa.us
Backpatch-through: 13

Fix resource leaks in PL/Python error reporting, redux.

Commit c6f7f11d8 intended to prevent leaking any PyObject reference
counts in edge cases (such as out-of-memory during string
construction), but actually it introduced a leak in the normal case.
Repeating an error-trapping operation often enough would lead to
session-lifespan memory bloat.  The problem is that I failed to
think about the fact that PyObject_GetAttrString() increments the
refcount of the returned PyObject, so that simply walking down the
list of error frame objects causes all but the first one to have
their refcount incremented.

I experimented with several more-or-less-complex ways around that,
and eventually concluded that the right fix is simply to drop the
newly-obtained refcount as soon as we walk to the next frame
object in PLy_traceback.  This sounds unsafe, but it's perfectly
okay because the caller holds a refcount on the first frame object
and each frame object holds a refcount on the next one; so the
current frame object can't disappear underneath us.

By the same token, we can simplify the caller's cleanup back to
simply dropping its refcount on the first object.  Cleanup of
each frame object will lead in turn to the refcount of the next
one going to zero.

I also added a couple of comments explaining why PLy_elog_impl()
doesn't try to free the strings acquired from PLy_get_spi_error_data()
or PLy_get_error_data().  That's because I got here by looking at a
Coverity complaint about how those strings might get leaked.  They
are not leaked, but in testing that I discovered this other leak.

Back-patch, as c6f7f11d8 was.  It's a bit nervous-making to be
putting such a fix into v13, which is only a couple weeks from its
final release; but I can't see that leaving a recently-introduced
leak in place is a better idea.

Author: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/1203918.1761184159@sss.pgh.pa.us
Backpatch-through: 13

Introduce "REFRESH SEQUENCES" for subscriptions.

This patch adds support for a new SQL command:
ALTER SUBSCRIPTION ... REFRESH SEQUENCES
This command updates the sequence entries present in the
pg_subscription_rel catalog table with the INIT state to trigger
resynchronization.

In addition to the new command, the following subscription commands have
been enhanced to automatically refresh sequence mappings:
ALTER SUBSCRIPTION ... REFRESH PUBLICATION
ALTER SUBSCRIPTION ... ADD PUBLICATION
ALTER SUBSCRIPTION ... DROP PUBLICATION
ALTER SUBSCRIPTION ... SET PUBLICATION

These commands will perform the following actions:
Add newly published sequences that are not yet part of the subscription.
Remove sequences that are no longer included in the publication.

This ensures that sequence replication remains aligned with the current
state of the publication on the publisher side.

Note that the actual synchronization of sequence data/values will be
handled in a subsequent patch that introduces a dedicated sequence sync
worker.

Author: Vignesh C <[email protected]>
Reviewed-by: Amit Kapila <[email protected]>
Reviewed-by: shveta malik <[email protected]>
Reviewed-by: Masahiko Sawada <[email protected]>
Reviewed-by: Hayato Kuroda <[email protected]>
Reviewed-by: Dilip Kumar <[email protected]>
Reviewed-by: Peter Smith <[email protected]>
Reviewed-by: Nisha Moond <[email protected]>
Reviewed-by: Shlok Kyal <[email protected]>
Reviewed-by: Chao Li <[email protected]>
Reviewed-by: Hou Zhijie <[email protected]>
Discussion: https://postgr.es/m/CAA4eK1LC+KJiAkSrpE_NwvNdidw9F2os7GERUeSxSKv71gXysQ@mail.gmail.com

pg_rewind: Extend code detecting relation files to work with WAL files

isRelDataFile() is renamed to getFileContentType(), extended so as it
becomes able to detect more file patterns than only relation files.  The
new file name pattern that can be detected is WAL files.

This refactoring has been suggested by Robert Haas.  This will be used
in a follow-up patch where we are looking at improving how WAL files are
processed by pg_rewind.  As of this change, WAL files are still handled
the same way as previously, always copied from the source to the target
server.

Extracted from a larger patch by the same authors.

Author: John Hsu <[email protected]>
Author: Justin Kwan <[email protected]>
Reviewed-by: Japin Li <[email protected]>
Reviewed-by: Srinath Reddy Sadipiralla <[email protected]>
Discussion: https://postgr.es/m/181b4c6fa9c.b8b725681941212.7547232617810891479@viggy28.dev

Add comments explaining overflow entries in the replication lag tracker.

Commit 883a95646a8 introduced overflow entries in the replication lag tracker
to fix an issue where lag columns in pg_stat_replication could stall when
the replay LSN stopped advancing.

This commit adds comments clarifying the purpose and behavior of overflow
entries to improve code readability and understanding.

Since commit 883a95646a8 was recently applied and backpatched to all
supported branches, this follow-up commit is also backpatched accordingly.

Author: Xuneng Zhou <[email protected]>
Reviewed-by: Fujii Masao <[email protected]>
Discussion: https://postgr.es/m/CABPTF7VxqQA_DePxyZ7Y8V+ErYyXkmwJ1P6NC+YC+cvxMipWKw@mail.gmail.com
Backpatch-through: 13

Fix coding style with "else".

The "else" code block having single statement with comments on a
separate line should have been surrounded by braces.

Reported-by: Chao Li <[email protected]>
Suggested-by: David Rowley <[email protected]>
Author: Tatsuo Ishii <[email protected]>
Discussion: https://postgr.es/m/20251020.125847.997839131426057290.ishii%40postgresql.org

Fix some misplaced comments in parallel_schedule

These are listing which other tests one of the tests in the subsequent
group depends on.  A couple of comments were located with unrelated
tests.

In passing, fix a small grammatical issue.

Noticed in passing while working on something else.

Author: David Rowley <[email protected]>

Add copyright notice to vacuum_horizon_floor.pl test.

Fix oversight in commit 303ba0573, which was backpatched through 14.

Reviewed-by: Michael Paquier <[email protected]>
Discussion: https://postgr.es/m/CAD21AoBeFdTJcwUfUYPcEgONab3TS6i1PB9S5cSXcBAmdAdQKw%40mail.gmail.com
Backpatch-through: 14

Fix incorrect zero extension of Datum in JIT tuple deform code

When JIT deformed tuples (controlled via the jit_tuple_deforming GUC),
types narrower than sizeof(Datum) would be zero-extended up to Datum
width.  This wasn't the same as what fetch_att() does in the standard
tuple deforming code.  Logically the values are the same when fetching
via the DatumGet*() marcos, but negative numbers are not the same in
binary form.

In the report, the problem was manifesting itself with:

ERROR: could not find memoization table entry

in a query which had a "Cache Mode: binary" Memoize node. However, it's
currently unclear what else is affected.  Anything that uses
datum_image_eq() or datum_image_hash() on a Datum from a tuple deformed by
JIT could be affected, but it may not be limited to that.

The fix for this is simple: use signed extension instead of zero
extension.

Many thanks to Emmanuel Touzery for reporting this issue and providing
steps and backup which allowed the problem to easily be recreated.

Reported-by: Emmanuel Touzery <[email protected]>
Author: David Rowley <[email protected]>
Discussion: https://postgr.es/m/DB8P194MB08532256D5BAF894F241C06393F3A@DB8P194MB0853.EURP194.PROD.OUTLOOK.COM
Backpatch-through: 13

Avoid assuming that time_t can fit in an int.

We had several places that used cast-to-unsigned-int as a substitute
for properly checking for overflow.  Coverity has started objecting
to that practice as likely introducing Y2038 bugs.  An extra
comparison is surely not much compared to the cost of time(NULL), nor
is this coding practice particularly readable.  Let's do it honestly,
with explicit logic covering the cases of first-time-through and
clock-went-backwards.

I don't feel a need to back-patch though: our released versions
will be out of support long before 2038, and besides which I think
the code would accidentally work anyway for another 70 years or so.

Fix type of infomask parameter in htup_details.h functions.

Oversight in commit 34694ec888.  Since there aren't any known live
bugs related to this, no back-patch.

Reviewed-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/aPk4u955ZPPZ_nYw%40nathan

Remove useless pstrdup() calls.

The result of PLyUnicode_AsString is already palloc'd,
so pstrdup'ing it is just a waste of time and memory.
More importantly it might confuse people about whether
that's necessary.  Doesn't seem important enough to
back-patch, but we should fix it.  Spotted by Coverity.

Fix memory leaks in scripts/vacuuming.c.

Coverity complained that the list of table names returned by
retrieve_objects() was leaked, and it's right.  Potentially this
is quite a lot of memory; however, it's not entirely clear how much
we gain by cleaning it up, since in many operating modes we're going
to need the list until the program is about to exit.  Still, it will
win in some cases, so fix the leak.

vacuuming.c is new in v19, and this patch doesn't apply at all cleanly
to the predecessor code in v18.  I'm not excited enough about the
issue to devise a back-patch.

Fix memory leaks in pg_combinebackup/reconstruct.c.

One code path forgot to free the separately-malloc'd filename
part of a struct rfile.  Another place freed the filename but
forgot the struct rfile itself.  These seem worth fixing because
with a large backup we could be dealing with many files.

Coverity found the bug in make_rfile().  I found the other one
by manual inspection.

Remove make_temptable_name_n().

This small function is only used in one place, and it fails to
handle quoted table names (although the table name portion of the
input should never be quoted in current usage).  In addition to
removing make_temptable_name_n() in favor of open-coding it where
needed, this commit ensures the "diff" table name is properly
quoted in order to future-proof this area a bit.

Author: Aleksander Alekseev <[email protected]>
Reviewed-by: Álvaro Herrera <[email protected]>
Reviewed-by: Shinya Kato <[email protected]>
Discussion: https://postgr.es/m/CAJ7c6TO3a5q2NKRsjdJ6sLf8isVe4aMaaX1-Hj2TdHdhFw8zRA%40mail.gmail.com

Make invalid primary_slot_name follow standard GUC error reporting.

Previously, if primary_slot_name was set to an invalid slot name and
the configuration file was reloaded, both the postmaster and all other
backend processes reported a WARNING. With many processes running,
this could produce a flood of duplicate messages. The problem was that
the GUC check hook for primary_slot_name reported errors at WARNING
level via ereport().

This commit changes the check hook to use GUC_check_errdetail() and
GUC_check_errhint() for error reporting. As with other GUC parameters,
this causes non-postmaster processes to log the message at DEBUG3,
so by default, only the postmaster's message appears in the log file.

Backpatch to all supported versions.

Author: Fujii Masao <[email protected]>
Reviewed-by: Chao Li <[email protected]>
Reviewed-by: Amit Kapila <[email protected]>
Reviewed-by: Álvaro Herrera <[email protected]>
Reviewed-by: Hayato Kuroda <[email protected]>
Discussion: https://postgr.es/m/CAHGQGwFud-cvthCTfusBfKHBS6Jj6kdAPTdLWKvP2qjUX6L_wA@mail.gmail.com
Backpatch-through: 13

Fix multi WinGetFuncArgInFrame/Partition calls with IGNORE NULLS.

Previously it was mistakenly assumed that there's only one window
function argument which needs to be processed by WinGetFuncArgInFrame
or WinGetFuncArgInPartition when IGNORE NULLS option is specified. To
eliminate the limitation, WindowObject->notnull_info is modified from
"uint8 *" to "uint8 **" so that WindowObject->notnull_info could store
pointers to "uint8 *" which holds NOT NULL info corresponding to each
window function argument. Moreover, WindowObject->num_notnull_info is
changed from "int" to "int64 *" so that WindowObject->num_notnull_info
could store the number of NOT NULL info corresponding to each function
argument. Memories for these data structures will be allocated when
WinGetFuncArgInFrame or WinGetFuncArgInPartition is called. Thus no
memory except the pointers is allocated for function arguments which
do not call these functions

Also fix the set mark position logic in WinGetFuncArgInPartition to
not raise a "cannot fetch row before WindowObject's mark position"
error in IGNORE NULLS case.

Reported-by: Tom Lane <[email protected]>
Author: Tatsuo Ishii <[email protected]>
Discussion: https://postgr.es/m/2952409.1760023154%40sss.pgh.pa.us

Fix stalled lag columns in pg_stat_replication when replay LSN stops advancing.

Previously, when the replay LSN reported in feedback messages from a standby
stopped advancing, for example, due to a recovery conflict, the write_lag and
flush_lag columns in pg_stat_replication would initially update but then stop
progressing. This prevented users from correctly monitoring replication lag.

The problem occurred because when any LSN stopped updating, the lag tracker's
cyclic buffer became full (the write head reached the slowest read head).
In that state, the lag tracker could no longer compute round-trip lag values
correctly.

This commit fixes the issue by handling the slowest read entry (the one
causing the buffer to fill) as a separate overflow entry and freeing space
so the write and other read heads can continue advancing in the buffer.
As a result, write_lag and flush_lag now continue updating even if the reported
replay LSN remains stalled.

Backpatch to all supported versions.

Author: Fujii Masao <[email protected]>
Reviewed-by: Chao Li <[email protected]>
Reviewed-by: Shinya Kato <[email protected]>
Reviewed-by: Xuneng Zhou <[email protected]>
Discussion: https://postgr.es/m/CAHGQGwGdGQ=1-X-71Caee-LREBUXSzyohkoQJd4yZZCMt24C0g@mail.gmail.com
Backpatch-through: 13

Bump catalog version for new function error_on_null()

Oversight in 2b75c38b707a.  No comments.

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

Add error_on_null(), checking if the input is the null value

This polymorphic function produces an error if the input value is
detected as being the null value; otherwise it returns the input value
unchanged.

This function can for example become handy in SQL function bodies, to
enforce that exactly one row was returned.

Author: Joel Jacobson <[email protected]>
Reviewed-by: Vik Fearing <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>
Discussion: https://postgr.es/m/ece8c6d1-2ab1-45d5-ba12-8dec96fc8886@app.fastmail.com
Discussion: https://postgr.es/m/de94808d-ed58-4536-9e28-e79b09a534c7@app.fastmail.com

Use CompactAttribute more often, when possible

5983a4cff added CompactAttribute for storing commonly used fields from
FormData_pg_attribute.  5983a4cff didn't go to the trouble of adjusting
every location where we can use CompactAttribute rather than
FormData_pg_attribute, so here we change the remaining ones.

There are some locations where I've left the code using
FormData_pg_attribute.  These are mostly in the ALTER TABLE code.  Using
CompactAttribute here seems more risky as often the TupleDesc is being
changed and those changes may not have been flushed to the
CompactAttribute yet.

I've also left record_recv(), record_send(), record_cmp(), record_eq()
and record_image_eq() alone as it's not clear to me that accessing the
CompactAttribute is a win here due to the FormData_pg_attribute still
having to be accessed for most cases.  Switching the relevant parts to
use CompactAttribute would result in having to access both for common
cases.  Careful benchmarking may reveal that something can be done to
make this better, but in absence of that, the safer option is to leave
these alone.

In ReorderBufferToastReplace(), there was a check to skip attnums < 0
while looping over the TupleDesc.  Doing this is redundant since
TupleDescs don't store < 0 attnums.  Removing that code allows us to
move to using CompactAttribute.

The change in validateDomainCheckConstraint() just moves fetching the
FormData_pg_attribute into the ERROR path, which is cold due to calling
errstart_cold() and results in code being moved out of the common path.

Author: David Rowley <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>
Discussion: https://postgr.es/m/CAApHDvrMy90o1Lgkt31F82tcSuwRFHq3vyGewSRN=-QuSEEvyQ@mail.gmail.com

Avoid short seeks in pg_restore.

If a data block to be skipped over is less than 4kB, just read the
data instead of using fseeko().  Experimentation shows that this
avoids useless kernel calls --- possibly quite a lot of them, at
least with current glibc --- while not incurring any extra I/O,
since libc will read 4kB at a time anyway.  (There may be platforms
where the default buffer size is different from 4kB, but this
change seems unlikely to hurt in any case.)

We don't expect short data blocks to be common in the wake of
66ec01dc4 and related commits.  But older pg_dump files may well
contain very short data blocks, and that will likely be a case
to be concerned with for a long time.

While here, do a little bit of other cleanup in _skipData.
Make "buflen" be size_t not int; it can't really exceed the
range of int, but comparing size_t and int variables is just
asking for trouble.  Also, when we initially allocate a buffer
for reading skipped data into, make sure it's at least 4kB to
reduce the odds that we'll shortly have to realloc it bigger.

Author: Dimitrios Apostolou <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/2edb7a57-b225-3b23-a680-62ba90658fec@gmx.net

Add reminder to create .abi-compliance-history.

This commit adds a note to RELEASE_CHANGES to remind us to create
an .abi-compliance-history file for new major versions.

Reviewed-by: Tom Lane <[email protected]>
Reviewed-by: David E. Wheeler <[email protected]>
Discussion: https://postgr.es/m/aPJ03E2itovDBcKX%40nathan

Make char2wchar() static.

Reviewed-by: Peter Eisentraut <[email protected]>
Discussion: https://postgr.es/m/0151ad01239e2cc7b3139644358cf8f7b9622ff7[email protected]

Remove obsolete global database_ctype_is_c.

Now that tsearch uses the database default locale, there's no need to
track the database CTYPE separately.

Reviewed-by: Peter Eisentraut <[email protected]>
Discussion: https://postgr.es/m/0151ad01239e2cc7b3139644358cf8f7b9622ff7[email protected]

tsearch: use database default collation for parsing.

Previously, tsearch used the database's CTYPE setting, which only
matches the database default collation if the locale provider is libc.

Note that tsearch types (tsvector and tsquery) are not collatable
types. The locale affects parsing the original text, which is a lossy
process, so a COLLATE clause on the already-parsed value would not
make sense.

Reviewed-by: Peter Eisentraut <[email protected]>
Discussion: https://postgr.es/m/0151ad01239e2cc7b3139644358cf8f7b9622ff7[email protected]

Add previous commit to .git-blame-ignore-revs.

Backpatch-through: 13

Re-pgindent brin.c.

Backpatch-through: 13

Make smgr access for a BufferManagerRelation safer in relcache inval

Currently there's no bug, because we have no code path where we
invalidate relcache entries where it'd cause a problem.  But it's more
robust to do it this way in case we introduce such a path later, as some
Postgres forks reportedly already have.

Author: Daniil Davydov <[email protected]>
Reviewed-by: Stepan Neretin <[email protected]>
Discussion: https://postgr.es/m/CAJDiXgj3FNzAhV+jjPqxMs3jz=OgPohsoXFj_fh-L+nS+13CKQ@mail.gmail.com

Fix BRIN 32-bit counter wrap issue with huge tables

A BlockNumber (32-bit) might not be large enough to add bo_pagesPerRange
to when the table contains close to 2^32 pages.  At worst, this could
result in a cancellable infinite loop during the BRIN index scan with
power-of-2 pagesPerRange, and slow (inefficient) BRIN index scans and
scanning of unneeded heap blocks for non power-of-2 pagesPerRange.

Backpatch to all supported versions.

Author: sunil s <[email protected]>
Reviewed-by: David Rowley <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>
Discussion: https://postgr.es/m/CAOG6S4-tGksTQhVzJM19NzLYAHusXsK2HmADPZzGQcfZABsvpA@mail.gmail.com
Backpatch-through: 13