Prevent access to other sessions' empty temp tables
Commit ce146621 ensures that ERROR is raised if a session tries to read
pages of another session's temp table. But there is a corner case where
the other session's temp table is empty -- in this case the INSERT
command bypasses our checks and executes without any errors.
Such behavior is inconsistent and erroneous: it leaves an invalid buffer
in the temp buffers pool. Since the buffer was created for another
session's temp table, we get an error "no such file or directory" when
trying to flush it.
This commit fixes it by adding a RELATION_IS_OTHER_TEMP check in the
relation-extension path.
Backpatch to 16, because it is the first release after 31966b151e6, which
introduced a separate local relation extension function
ExtendBufferedRelLocal(), which lacks of RELATION_IS_OTHER_TEMP() check.
As this fix introduces more checks to 013_temp_obj_multisession.pl, backpatch
the whole test script to 16.
Discussion: https://postgr.es/m/CAJDiXgiX2XZBHDNo%2BzBbvku%2BtchrUurvPRaN1_40mEQ1_sG90g%40mail.gmail.com
Author: Daniil Davydov <3danissimo@gmail.com> Reviewed-by: Jim Jones <jim.jones@uni-muenster.de> Reviewed-by: Imran Zaheer <imran.zhir@gmail.com> Reviewed-by: ZizhuanLiu X-MAN <44973863@qq.com>
Backpatch-through: 16
Fix handling of dropping a property not associated with the given label
When dropping a property by name from a label, the code checked only
whether the property existed in the graph's property catalog. It did
not verify that the property was actually associated with the given
label, resulting in passing InvalidOid to performDeletion(). Fix it
by explicilty checking the label property association.
While at it also rearrange the code so as to avoid multiple ereport
calls for the same error in the same block.
Author: Chao Li <lic@highgo.com> Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/1DA5D52A-4AFA-426E-83F7-42ED974D682B%40gmail.com
BackendKeyData length was increased from 4 bytes to a variable-length
length (up to 256 bytes) in a460251f0a. However, pqTrace still traces
it as a 4 bytes key, leading to a "mismatched message length" warning
message. The same issue impacts the tracing of CancelRequest.
This patch fixes the issue by using pqTraceOutputNchar instead of
pqTraceOutputInt32 in both cases.
Fix REPACK CONCURRENTLY for stored generated columns
In order to replay concurrent changes, REPACK CONCURRENTLY needs the
pg_attrdef tuples for the transient table to be there, in case a tuple
is modified concurrently with REPACK and requires to store the value
from the generated column (which, with the current arrangements, means
all tuples concurrently updated or inserted). Fix by creating a copy of
them from the original table. Add a test that tickles the bug.
Author: Antonin Houska <ah@cybertec.at> Reported-by: Ewan Young <kdbase.hack@gmail.com> Diagnosed-by: Ewan Young <kdbase.hack@gmail.com> Reviewed-by: Ewan Young <kdbase.hack@gmail.com>
Backpatch-through: 19
Discussion: https://postgr.es/m/CAON2xHMrELwx9vKg6niSf8fMBA=-MGXmG=MPQU6+vMVhGjF8kQ@mail.gmail.com
Prevent dropping the last label from a property graph element
Per SQL/PGQ standard, every graph element must have at least one
label. When dropping a label from a graph element, ensure that there
exists at least one other label on the element. If the label being
dropped is the only label on the element, raise an error.
We hold a ShareRowExclusiveLock when modifying a property graph.
Hence the label will not be dropped even when multiple labels are
being dropped concurrently.
Fix log_statement_max_length test with verbose logs
Buildfarm member prion reported a failure in the test added by commit c8bd8387c27 to verify that the server logs an empty statement body
when log_statement_max_length = 0.
The test assumed that "statement:" would appear immediately after
"LOG:" in the logged statement message. However, prion runs with
log_error_verbosity = verbose, which inserts the SQLSTATE between
"LOG:" and the message text. As a result, the test failed even though
the server behaved correctly.
Michael Paquier [Fri, 3 Jul 2026 03:07:30 +0000 (12:07 +0900)]
Switch Get[Local]BufferDescriptor() to use a signed value in input
GetBufferDescriptor() and GetLocalBufferDescriptor() took a uint32
buffer index, but every real caller derives the index from a Buffer:
- Unsigned value for shared buffers.
- Signed value for local buffers.
Both routines now take in input a signed number, GetBufferDescriptor()
gaining an assertion checking that the input value is in the range
allowed by the GUC shared_buffers. This work is a follow-up of e18b0cb7344c, where we found that passing down a value for a local
buffer was undetected and finished outside the range of NBuffers.
While monitoring all the existing callers of *BufferDescriptor(), the
only consumer that passes does an unsigned value is ClockSweepTick(),
whose result is always a module of NBuffers.
Suggested-by: Andres Freund <andres@anarazel.de>
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/CAExHW5uzRMYVZsXXS3HXXT0fG_sNrpUhUqwP4NorhaCqH9JDhA@mail.gmail.com
Remove replication slot advice from MultiXact wraparound hints
Previously, MultiXactId wraparound hints suggested dropping stale
replication slots. While that advice is appropriate for transaction ID
wraparound, where replication slots can hold back XID horizons,
it was misleading for MultiXactId wraparound. Following it could lead
users to drop replication slots unnecessarily without helping resolve
the MultiXactId wraparound condition.
MultiXact cleanup is not directly delayed by replication slots.
Instead, it depends on whether old MultiXactIds can still be seen
as live by running transactions.
This commit removes the replication slot advice from MultiXactId
wraparound hints, and documents that stale replication slots are
normally not relevant to resolving MultiXactId wraparound problems.
Add log_statement_max_length GUC to limit logged statement text
Very large statements can make server logs grow unexpectedly. This is
particularly painful when applications accidentally or intentionally
send huge literal values and statement logging is enabled: the full
statement text may be written to the log even when DBA sees only
its leading part is useful for normal operations.
This commit adds log_statement_max_length GUC that limits the number
of bytes of statement text emitted by statement logging. The setting
applies to statements logged by log_statement, log_min_duration_statement,
log_min_duration_sample, and log_transaction_sample_rate. A positive
value truncates the logged statement body to at most that many bytes,
zero logs an empty statement body, and the default value -1 preserves
the existing behavior of logging statements in full.
Truncation is byte-based, matching the GUC unit, but it clips only
at multibyte character boundaries so that the log output remains valid.
This setting does not affect statements logged because of
log_min_error_statement; handling error-statement logging can be
considered separately.
Robert Haas [Thu, 2 Jul 2026 19:45:22 +0000 (15:45 -0400)]
pg_plan_advice: Don't generate FOREIGN_JOIN advice for a single relation.
A foreign scan can target a single relation while still reaching the
fs_relids branch of pgpa_build_scan() -- for example, when postgres_fdw
pushes an aggregate down over one foreign table. In that case, no
advice should be emitted.
Run pgindent and pgperltidy for previous 3 commits.
For ease of review, and to be able to put the indentation changes
in .git-blame-ignore-revs, I did not fix the indentation of the
last 3 commits. Do that now.
Per discussion, it seems like a good time to bump the minimum
supported version for various applications. Our current policy is
to support at least 10 previous major versions, so this bumps the
minimum to v10 for the v20 release. For reference, the minimum was
last bumped to v9.2 in 2021 for v15 (see commits 30e7c175b8, e469f0aaf3, cf0cab868a, and 492046fa9e).
For ease of review, and to be able to put the indentation changes
in .git-blame-ignore-revs, I did not fix the indentation in this
patch. I'll push a separate pgindent commit after these changes
are applied.
Remove pg_upgrade support for upgrading from pre-v10 servers.
Per discussion, it seems like a good time to bump the minimum
supported version for various applications. Our current policy is
to support at least 10 previous major versions, so this bumps the
minimum to v10 for the v20 release. For reference, the minimum was
last bumped to v9.2 in 2021 for v15 (see commits 30e7c175b8, e469f0aaf3, cf0cab868a, and 492046fa9e).
For ease of review, and to be able to put the indentation changes
in .git-blame-ignore-revs, I did not fix the indentation in this
patch. I'll push a separate pgindent commit after these changes
are applied.
Remove pg_dump/pg_dumpall support for dumping from pre-v10 servers.
Per discussion, it seems like a good time to bump the minimum
supported version for various applications. Our current policy is
to support at least 10 previous major versions, so this bumps the
minimum to v10 for the v20 release. For reference, the minimum was
last bumped to v9.2 in 2021 for v15 (see commits 30e7c175b8, e469f0aaf3, cf0cab868a, and 492046fa9e). As in previous changes of
this sort, we aren't removing pg_restore's ability to read older
archive files, though it's fair to wonder how that might be tested
nowadays.
For ease of review, and to be able to put the indentation changes
in .git-blame-ignore-revs, I did not fix the indentation in this
patch. I'll push a separate pgindent commit after these changes
are applied.
John Naylor [Thu, 2 Jul 2026 08:53:44 +0000 (15:53 +0700)]
Use ssup_datum_*_cmp in more places
The int2, oid, and oid8 "fastcmp" comparators are functionally
equivalent to the ssup_datum_int32_cmp (for int2) and
ssup_datum_unsigned_cmp (for oid, oid8) functions added by commit 697492434, so simplify by using the latter instead. This has the
added benefit of making these types eligible for radix sort.
Author: Baji Shaik <baji.pgdev@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/CA+fm-RMyLC94NfrxCh273+dKs44U0ZJjRczznvzvgw=KtpPNVw@mail.gmail.com
Michael Paquier [Thu, 2 Jul 2026 06:52:46 +0000 (15:52 +0900)]
test_custom_stats: Fail if loading module outside shared_preload_libraries
Previously, test_custom_var_stats and test_custom_fixed_stats silently
skipped pgstat_register_kind() when not loaded via
shared_preload_libraries, behavior inherited from injection_points.
This left the SQL functions callable without the kind registered,
leading to various issues on the backend side.
This code is not designed to work without the pgstats kinds registered.
pgstat_register_kind() gets now called when these libraries are loaded,
with or without shared_preload_libraries, letting the registration fail
if loading the modules at a later step than startup. test_custom_rmgrs
does the same thing.
John Naylor [Thu, 2 Jul 2026 06:26:56 +0000 (13:26 +0700)]
Fix loss of precision in pg_stat_us_to_ms()
Multiplying by the constant 0.001 can produce trailing-digit noise in
displayed values (for example 0.009000000000000001 instead of 0.009,
with default extra_float_digits) because 0.001 cannot be represented
exactly in binary floating point. Use division by 1000.0 instead,
matching code elsewhere in the tree.
John Naylor [Thu, 2 Jul 2026 06:15:35 +0000 (13:15 +0700)]
Remove stale comment
Commit 732e6677a added a member to TimeoutType, invalidating the
comment on EnableTimeoutParams.type. Rather than documenting the list,
as is done for vars that should only take a subset of enum values,
just remove the comment.
Amit Kapila [Thu, 2 Jul 2026 04:04:17 +0000 (09:34 +0530)]
Expand comment on the slot recheck in drop_local_obsolete_slots().
The existing comment explained that a user-created slot could reuse the
same shared memory as 'local_slot' during the window between selecting a
slot to drop and locking its database, and that we therefore recheck
before dropping. It did not, however, spell out the fuller consequence:
because local_slot points to a reusable slot-array entry, its fields may
already describe a replacement slot, so the earlier drop decision and the
slot_database used for locking could relate to an unrelated slot/database.
Expand the comment to describe this, and note that the recheck prevents
us from dropping a user-created replacement slot while the residual risk
(such as briefly locking an unrelated database) is confined to the cycle
and is acceptable given the race is rare and non-fatal.
Michael Paquier [Thu, 2 Jul 2026 03:44:29 +0000 (12:44 +0900)]
Fix jsonpath .decimal() to honor silent mode
The jsonpath .decimal(precision[, scale]) method built its numeric
typmod by calling numerictypmodin() through DirectFunctionCall1(), which
can throw a hard error for an incorrect set of precision and/or scale
vaulues. This breaks the silent mode supported by this function, that
should not fail.
Most of the jsonpath code uses the soft error reporting to bypass
errors, which is what this fix does by avoiding a direct use of
numerictypmodin(). Its code is refactored to use a new routine called
make_numeric_typmod_safe(), able to take an error context in input.
numerictypmodin() sets no context, mapping to its previous behavior.
The jsonpath code sets or not a context depending on the use of the
silent mode. This result leads to some nice simplifications:
numerictypmodin() feeds on an array, we can now pass directly values for
the scale and precision.
Amit Kapila [Thu, 2 Jul 2026 02:14:27 +0000 (07:44 +0530)]
Allow logical replication conflicts to be logged to a table.
Until now, logical replication conflicts were only written as plain text
to the server log, which is hard to query, analyze, or feed into external
monitoring and automation.
This commit adds a conflict_log_destination option to CREATE SUBSCRIPTION
and ALTER SUBSCRIPTION that controls where conflicts are recorded. It
accepts 'log' (the existing behavior), 'table', or 'all'.
When table logging is enabled ('table' or 'all'), an internal log table
named pg_conflict_log_<subid> is created automatically in a dedicated,
system-managed pg_conflict namespace. Using a separate namespace avoids
collisions with user table names and lets the table be shielded from
direct modification. The table is tied to the subscription through an
internal dependency, so it is dropped automatically when the subscription
is removed.
The conflict details, including the local and remote tuples, are stored in
JSON columns, so a single table layout can accommodate rows from tables
with different schemas. The table also records the local and remote
transaction IDs, LSNs, commit timestamps, and the conflict type, providing
a complete record for post-mortem analysis.
A per-subscription table was chosen over a single global log because it
aligns table ownership with the subscription lifecycle. This keeps
permission management simple: the subscription owner can perform the
permitted maintenance operations without the security concerns or
Row-Level Security that a shared table would require.
Because the table is system-managed, it is protected from direct
manipulation: DDL (such as ALTER, DROP, CREATE INDEX, and adding a
trigger, rule, policy, or extended statistics), use as an inheritance
parent or a foreign-key target, and manual INSERT, UPDATE, MERGE, or row
locking are all rejected. Only DELETE and TRUNCATE are permitted, so that
users can prune old conflict rows.
Conflict log tables are also excluded from publications, even those
defined with FOR ALL TABLES or FOR TABLES IN SCHEMA.
This commit only establishes the conflict log table along with its
creation, cleanup, and protection; recording the conflicts detected
during apply into the table will be handled in a follow-up commit.
Author: Dilip Kumar <dilipbalaut@gmail.com>
Author: Nisha Moond <nisha.moond412@gmail.com>
Author: Amit Kapila <akapila@postgresql.org> Reviewed-by: Shveta Malik <shveta.malik@gmail.com> Reviewed-by: Vignesh C <vignesh21@gmail.com> Reviewed-by: Peter Smith <smithpb2250@gmail.com> Reviewed-by: Shlok Kyal <shlok.kyal.oss@gmail.com> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>
Discussion: https://postgr.es/m/CAFiTN-u5D5o_AGNbHRZHaOqAMWkxLf%2BhSk_r9X3gv6HbLOB5%2Bg%40mail.gmail.com
Michael Paquier [Thu, 2 Jul 2026 00:34:21 +0000 (09:34 +0900)]
Add system view pg_stat_kind_info
This commit adds support for pg_stat_kind_info, that exposes at SQL
level data about the statistics kinds registered into a backend:
- Meta-data of a stats kind (built-in or custom, some properties).
- Number of entries, if tracking is enabled.
We have discussed the possibility of more fields (like shared memory
size for a single entry); this adds the minimum agreed on.
This is in spirit similar to pg_get_loaded_modules() for custom stats
kinds, this view providing detailed information about the stats kinds
when registered through shared_preload_libraries.
Bump catalog version.
Author: Tristan Partin <tristan@partin.io> Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> Reviewed-by: Sami Imseih <samimseih@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/DI6OFGHJ1B69.25YVDEP3BABRH@partin.io
The uuid type already has a full set of comparison operators and a
btree operator class, so it is totally ordered. min() and max() were
the only common aggregates missing for it. Add the uuid_larger() and
uuid_smaller() support functions and register the min(uuid) and
max(uuid) aggregates that use them.
uuid values are compared lexicographically over their 128 bits. For
UUIDv7, whose most significant bits encode a Unix timestamp, this
coincides with chronological order, so min() and max() return the
oldest and newest values.
Tom Lane [Wed, 1 Jul 2026 17:44:45 +0000 (13:44 -0400)]
Fix macro-redefinition warning introduced by aeb07c55f.
Some platforms provide a definition of unreachable() in standard C
headers, leading to a conflict with unreachable() in the new
timezone code. It seems best for our purposes to conform to what
pg_unreachable() does, so #undef away the platform version.
Tom Lane [Wed, 1 Jul 2026 17:27:22 +0000 (13:27 -0400)]
btree_gist: fix NaN handling in float4/float8 opclasses.
The float4 and float8 btree_gist opclasses compared keys with raw C
operators (==, <, >). IEEE 754 makes every comparison involving NaN
false, so GiST disagreed with the regular float comparison operators
and with the btree opclass, which uses float[4|8]_cmp_internal()
(so that all NaNs are equal and NaN sorts after every non-NaN value).
In addition, the penalty and distance functions were not careful
about NaNs, and the penalty functions could also misbehave for IEEE
infinities. Wrong answers from the penalty functions would probably
do no more than make the index non-optimal, but the distance mistakes
were visible from SQL.
To fix, make the comparison functions rely on the same NaN-aware
comparison functions the core code uses, and rewrite the penalty
and distance functions to follow the rules that NaNs are equal
but maximally far away from non-NaNs. The penalty_num() code was
formerly shared between integral and float cases, but I chose to make
two copies so that the integral cases are not saddled with the extra
logic for NaNs and infinities/overflows. I also rewrote it as static
inline functions instead of an unreadable and uncommented macro.
The float penalty functions were previously unreached by the
regression tests, so add new test cases to exercise them.
There's no on-disk format change, but users who have NaN entries
in a btree_gist index would be well advised to reindex it.
Bug: #19501
Bug: #19524 Reported-by: Man Zeng <zengman@halodbtech.com> Reported-by: Yuelin Wang <3020001251@tju.edu.cn>
Author: Bill Kim <billkimjh@gmail.com> Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/19501-3bff3bbc97f1e7c9@postgresql.org
Discussion: https://postgr.es/m/19524-9559d302c8455664@postgresql.org
Discussion: https://postgr.es/m/CAMQXxcgbtD2LXfX0tpgvOizxP-XxrCHV2ZDy4By_TZnJMsxXWQ@mail.gmail.com
Backpatch-through: 14
The descriptions of the component scores state that values greater
than or equal to the corresponding weight parameter mean autovacuum
will process the table. However, since the code that determines
whether to vacuum or analyze a table actually checks whether the
threshold is exceeded, it's more accurate to say "greater than"
there.
Author: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Sami Imseih <samimseih@gmail.com>
Discussion: https://postgr.es/m/E3ABDC6B-80CA-4C37-BA0B-A519D49F4C66%40gmail.com
Backpatch-through: 19
Tom Lane [Wed, 1 Jul 2026 15:33:52 +0000 (11:33 -0400)]
Improve the names generated for indexes on expressions.
If the user doesn't specify a name for an index, it's generated
based on the names chosen for the index columns (which the user
has no direct control over). For index columns that are just
columns of the base relation, the index column name is the same as
the base column name; but for index columns that are expressions,
it's less clear what to do. Up to now, what we have done is
equivalent to the heuristics used to choose SELECT output column
names, except that we fall back to "expr" not "?column?" in the
numerous cases that FigureColname doesn't know what to do with.
This is not tremendously helpful. More, it frequently leads to
collisions of generated index names, which we can handle but
only at the cost of user confusion; also there's some risk of
concurrent index creations trying to use the same name.
Let's try to do better.
Messing with the FigureColname heuristics would have a very
large blast radius, since that affects the column headings
that applications see. That doesn't seem wise, but fortunately
SQL queries are seldom directly concerned with index names.
So we should be able to change the index-name generation rules
as long as we decouple them from FigureColname.
The method used in this patch is to dig through the expression,
extract the names of Vars, the string representations of Consts,
and the names of functions, and run those together with underscores
between. Other expression node types are ignored but descended
through. We could work harder by handling more node types, but
it seems like this is likely to be sufficient to arrive at unique
index names in many cases.
Notably, this rule ignores the names of operators, for example
both "a + b" and "a * b" will be rendered as "a_b". This choice
was made to reduce the probability of having to double-quote
the index name.
I've also chosen to strip Const representations down to only
alphanumeric characters (plus non-ASCII characters, which our
parser treats as alphabetic anyway). So for example "x + 1.0"
would be represented as "x_10". This likewise avoids possible
quoting problems. I also considered limiting how many characters
we'd take from each Const, but didn't do that here.
We might tweak these rules some more after we get some experience
with this patch. It's being committed at the start of a
development cycle to provide as much time as possible to gather
feedback.
Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Robert Haas <robertmhaas@gmail.com>
Discussion: https://postgr.es/m/876799.1757987810@sss.pgh.pa.us
Discussion: https://postgr.es/m/18959-f63b53b864bb1417@postgresql.org
Tom Lane [Wed, 1 Jul 2026 14:56:46 +0000 (10:56 -0400)]
Sync our copy of the timezone library with IANA release tzcode2026b.
This was moderately tedious, because upstream has been busy
since we last did this in 2020.
Notably, they changed the signatures of both tzload() and tzparse(),
which we'd unwisely exposed as API for callers to use. I concluded
that the best answer was to change them both back to "static" and
instead expose a new API function of our own choosing, pg_tzload().
That change may be a sufficient reason not to back-patch this update,
as I'd normally want to do. There's probably not a good reason for
extensions to be calling those functions, but on the other hand
there are few pressing reasons for a back-patch. The one bug we have
run into (a Valgrind uninitialized-data complaint about zic) appears
to have no field-visible consequences.
A few of the files generated by this version of zic are not
byte-for-byte the same as before, but "zdump -v" avers that
they represent the same sets of transitions.
Tom Lane [Wed, 1 Jul 2026 14:10:21 +0000 (10:10 -0400)]
Fix CPU-identification macros for RISC-V.
Turns out that RISC-V intentionally doesn't follow the common
naming pattern for CPU-identification macros. But the point of 2ef57e636 is to have a common pattern, so we're going to override
their opinion.
Previously, if a base backup failed after it had started streaming
files, pg_stat_progress_basebackup could continue to show a stale
progress entry even though the backup was no longer running. This could
be observed when the client kept the replication connection open after
the error. It is normally not observable when using pg_basebackup,
because the client disconnects after the error.
The problem was that progress reporting was cleared only after
successful completion.
This commit moves the progress reporting cleanup into the progress
sink's cleanup callback so that it is cleared after both successful
and failed backups.
Backpatch to v15. v14 has the same issue, but the fix does not apply
cleanly because it lacks the base backup sink infrastructure. Since
the bug does not affect the backup itself and is normally not
observable when using pg_basebackup, skip the v14 backpatch.
Warn on password auth with MD5-encrypted passwords
Commit bc60ee860 added a connection warning after successful MD5
authentication, but only for the md5 authentication method. A role with
an MD5-encrypted password can also authenticate via the password method,
which left that path without the same deprecation warning.
Emit the MD5 deprecation connection warning after successful
password authentication as well, when the stored password is
MD5-encrypted.
Backpatch to v19, where the MD5 connection warning was introduced.
Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Japin Li <japinli@hotmail.com>
Discussion: https://postgr.es/m/CAHGQGwGkWfn5rtHzvdRbVk+PCefQU3gun3hc7QnaMXHFa5Bu3w@mail.gmail.com
Backpatch-through: 19
In fe_memutils.h, we have various allocation functions beginning with
either pg_ or p. The pg_ functions have a matching pg_free() for
freeing memory, while the p functions use pfree(). In some cases, we
were allocating memory with one set of functions while using the wrong
deallocation functions. This creates a tiny bit of mental overhead
when reading code. Matching up allocation and deallocation functions
makes it easier to analyze memory handling in a code path.
Don't cast off_t to 32-bit type for output, bug fix
off_t is most likely a 64-bit integer, so casting it to a 32-bit type
for output could lose data. There are more issues like this in the
tree, but this is an instance where this could actually happen in
practice, since base backups are routinely larger than 4 GB. So this
is separated out as a bug fix.
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>
Discussion: https://www.postgresql.org/message-id/flat/20ce62fa-47fc-457b-b504-12f3c1651726%40eisentraut.org
Peter Eisentraut [Mon, 29 Jun 2026 08:46:51 +0000 (10:46 +0200)]
Use C11 alignas instead of pg_attribute_aligned
Replace pg_attribute_aligned with C11 alignas, for consistency with
current conventions.
(These new uses were added by commit fbc57f2bc2e, which was developed
concurrently with the switch from pg_attribute_aligned to C11 standard
alignas, and it ended up being committed with the "old" style.)
Reviewed-by: John Naylor <johncnaylorls@gmail.com>
Discussion: https://postgr.es/m/CANWCAZaKhE+RD5KKouUFoxx1EbUNrNhcduM1VQ=DkSDadNEFng@mail.gmail.com
Richard Guo [Wed, 1 Jul 2026 06:12:43 +0000 (15:12 +0900)]
Improve UNION's output row count estimate
A UNION (not UNION ALL) removes duplicates, so its output has no more
rows than its input. The planner did not account for this: it set the
set-op relation's row count to the total size of the appended input,
as though dedup removed nothing. That inflated estimate then
propagated to every node above the UNION, leading to poor plan choices
such as a hash join with a full table scan where an index nested loop
would have been cheaper.
This patch estimates the number of distinct output rows as the sum of
the per-child distinct-group estimates instead. This relies on the
fact that:
distinct(A union B) <= distinct(A) + distinct(B)
that is, the union cannot have more distinct rows than its children do
in total. And because each child's distinct-group estimate never
exceeds that child's row-count estimate, this sum is never larger than
the old estimate, so it only tightens the previous over-estimate.
Author: Richard Guo <guofenglinux@gmail.com> Reviewed-by: David Rowley <dgrowleyml@gmail.com> Reviewed-by: Chengpeng Yan <chengpeng_yan@outlook.com>
Discussion: https://postgr.es/m/CAMbWs48Fu1nhGXPa60oc+adj7ge4dn0nHhqngqKvOVVQP61duA@mail.gmail.com
Michael Paquier [Wed, 1 Jul 2026 03:17:17 +0000 (12:17 +0900)]
Avoid useless calls in pg_get_multixact_stats()
MultiXactOffsetStorageSize() and GetMultiXactInfo() are called to gather
the information reported by the function, but were wasteful for the case
where a role does not have the privileges of pg_read_all_stats, where we
return a set of NULLs. These calls are moved to the code path where
their results are used.
John Naylor [Wed, 1 Jul 2026 01:50:08 +0000 (08:50 +0700)]
Document wal_compression=on
Commit 4035cd5d4 added LZ4 compression for full-page writes in WAL, and
retained "on" as a backward-compatible way to specify the builtin PGLZ
method. Document this meaning of "on" and update postgresql.conf.sample
to make the equivalence clear.
Author: Christoph Berg <myon@debian.org> Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/akJDHRtXwGLTppsQ@msg.df7cb.de
Backpatch-through: 15
Michael Paquier [Wed, 1 Jul 2026 01:08:26 +0000 (10:08 +0900)]
doc: Add new section describing fast-path locking
Fast-path locking is referenced by pg_stat_lock.fastpath_exceeded, by
pg_locks.fastpath, and in the GUC max_locks_per_transaction. However,
the documentation has never described in details how this works; one
would need to look at the internals of lock.c, mostly around
EligibleForRelationFastPath().
This commit adds a new subsection called "Fast-Path Locking" to the area
dedicated to locks, with the three places mentioned above linking to it.
Thomas Munro [Tue, 30 Jun 2026 23:25:37 +0000 (11:25 +1200)]
Remove radius from initdb authentication methods.
Commit a1643d40b removed RADIUS authentication, but apparently
overlooked initdb's list of accepted authentication methods. As a
result, initdb still accepted radius for --auth, --auth-host, and
--auth-local, allowing it to create a pg_hba.conf that the server could
not load.
Remove radius from initdb's local and host authentication method lists.
Backpatch-through: 19
Author: Chao Li <lic@highgo.com>
Discussion: https://postgr.es/m/983F946B-A7CE-4C93-B5F0-665616F72254%40gmail.com
Tom Lane [Tue, 30 Jun 2026 21:21:23 +0000 (17:21 -0400)]
Disallow set-returning functions within window OVER clauses.
We previously allowed this, but it leads to odd behaviors, basically
because putting a SRF there is inconsistent with the principle that a
window function doesn't change the number of rows in the query result.
There doesn't seem to be a strong reason to try to make such cases
behave consistently. Users should put their SRFs in lateral FROM
clauses instead.
This issue has been sitting on the back burner for multiple years
now, partially because it didn't seem wise to back-patch such a
change. Let's squeeze it into v19 before it's too late.
Bug: #17502
Bug: #19535 Reported-by: Daniel Farkaš <daniel.farkas@datoris.com> Reported-by: Qifan Liu <imchifan@163.com>
Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: David Rowley <dgrowleyml@gmail.com>
Discussion: https://postgr.es/m/17502-281a7aaacfaa872a@postgresql.org
Discussion: https://postgr.es/m/19535-376081d7cc07c86d@postgresql.org
Backpatch-through: 19
The existing description says the ranges of merged range-partitions
"must be adjacent" only under the heading "If the DEFAULT partition is
not in the list of merged partitions". That could be misread as
a restriction tied to the presence of a default partition. In fact,
merging non-adjacent ranges is rejected regardless of whether
the partitioned table has a default partition; spell that out explicitly.
Also, this commit removes a small redundancy in the documentation sentence
stating that "merged range-partitions" are "to be merged".
Tom Lane [Tue, 30 Jun 2026 16:21:06 +0000 (12:21 -0400)]
Clean up inconsistencies in CPU-identification macros.
In various places we depend on compiler-defined macros like __x86_64__
to guard CPU-type-specific code. However, those macros aren't very
well standardized; in particular, it emerges that MSVC doesn't define
any of the ones gcc does, but has its own. We were not coping with
that consistently, with the result that we're missing some useful
CPU-dependent optimizations in MSVC builds. There are also some
places that are checking randomly-different spellings that may
have been the only ones recognized by some old compilers, but we
weren't doing that consistently either.
Let's standardize on using gcc's long-form spellings (with trailing
underscores), after putting a stanza into c.h that ensures that these
spellings are defined even when the compiler provides some other one.
I put an "#else #error" branch into the c.h addition so that we'll
get an error if the compiler provides none of the symbols we're
expecting. That might be best removed in the end, since it might
annoy people trying to port to some new CPU type. But for testing
this it seems like a good idea, in case we've missed some common
variant spelling.
In addition to enabling some optimizations we previously missed on
MSVC, this cleans up a thinko. Several places used "_M_X64" in the
apparent belief that that's MSVC's equivalent to __x86_64__, but
it's not: it will also get defined on some but not all ARM64 builds.
Also, guard the x86_feature_available() stuff in pg_cpu.[hc] with
#if defined(__x86_64__) || defined(__i386__)
which seems like a more natural way of specifying what it applies to.
This builds on some previous work by Thomas Munro, but it requires
much less code churn because it re-uses gcc's names for the CPU-type
macros instead of inventing our own.
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CA+hUKGL8Hs-phHPugrWM=5dAkcT897rXyazYzLw-Szxnzgx-rA@mail.gmail.com
Discussion: https://postgr.es/m/3035145.1780503430@sss.pgh.pa.us
Peter Eisentraut [Tue, 30 Jun 2026 13:43:56 +0000 (15:43 +0200)]
Make SPI_prepare argtypes argument const
This changes the argtypes argument of SPI_prepare(),
SPI_prepare_cursor(), SPI_cursor_open_with_args(), and
SPI_execute_with_args() from Oid *argtypes to const Oid *argtypes.
The underlying functions were already receptive to that, so this
doesn't require any significant changes beyond the function signatures
and some internal variables.
Commit 28972b6fc3dc recently introduced a case where a const had to be
cast away before calling these functions. This is fixed here.
In passing, make a very similar const addition to SPI_modifytuple().
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Ewan Young <kdbase.hack@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/86b5162f-c472-40fa-997b-0450dece1dec%40eisentraut.org
Peter Eisentraut [Tue, 30 Jun 2026 12:03:10 +0000 (14:03 +0200)]
Fixes for SPI "const Datum *" use
Fixup for commit 8a27d418f8f, which converted many functions to use
"const Datum *" instead of "Datum *", including some SPI functions.
For SPI_cursor_open(), the code was updated but not the documentation.
For SPI_cursor_open_with_args(), the documentation was updated but not
the code. (Possibly, these two were confused with each other.) Also,
SPI_execp() and SPI_modifytuple() were not updated, even though they
are closely related to the functions touched by the previous commit
and now look inconsistent. Fix all these.
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/86b5162f-c472-40fa-997b-0450dece1dec%40eisentraut.org
Michael Paquier [Tue, 30 Jun 2026 07:59:20 +0000 (16:59 +0900)]
Add backend-level lock statistics
This commit adds per-backend lock statistics, providing the same
information as pg_stat_lock. It is now possible to retrieve those stats
(lock wait counts, wait times, and fast-path exceeded count) on a
per-backend basis.
This data can be retrieved with a new system function called
pg_stat_get_backend_lock(), that returns one tuple per lock type based
on the PID provided in input. Like pg_stat_get_backend_io(), this is
useful if joined with pg_stat_activity to get a live picture of the
locks behavior for each running backend.
pgstat_flush_backend() gains a new flag value, able to control the flush
of the lock stats.
This commit is straight-forward, relying on the infrastructure provided
by 9aea73fc61d4 (backend-level pgstats).
Bump catalog version. No need to touch PGSTAT_FILE_FORMAT_ID as backend
statistics are never written to disk.
Michael Paquier [Tue, 30 Jun 2026 07:24:34 +0000 (16:24 +0900)]
Refactor pg_stat_get_lock() to use a helper function
This commit extracts the tuple-building logic from pg_stat_get_lock()
into a new static helper pg_stat_lock_build_tuples(). This is in
preparation for a follow-up patch, to add support for backend-level lock
stats, which will reuse the same helper.
This change follows the pattern established by pg_stat_io_build_tuples()
for IO stats and pg_stat_wal_build_tuple() for WAL stats.
Michael Paquier [Tue, 30 Jun 2026 07:16:56 +0000 (16:16 +0900)]
Use placeholders and not GUC names in error message (autovacuum)
A placeholder %s is now used instead of the GUC names in the error
string of this routine. This is going to be useful for a follow-up
patch, where we will be able to reuse the same string, hence reducing
the translation work.
Michael Paquier [Tue, 30 Jun 2026 03:47:34 +0000 (12:47 +0900)]
Change stat_lock.wait_time to double precision
Other statistics views (pg_stat_io, pg_stat_database, etc.) use float8
for all measured-time columns, the new pg_stat_lock standing out as an
outlier by using bigint.
This commit aligns pg_stat_lock with the other stats views for
consistency. Like pg_stat_io, the time is stored in microseconds, and
is displayed in milliseconds with a conversion done when the view is
queried.
While on it, replace a use of "long" by PgStat_Counter, the former could
overflow for large wait times where sizeof(long) is 4 bytes (aka WIN32).
Fujii Masao [Tue, 30 Jun 2026 01:30:47 +0000 (10:30 +0900)]
bufmgr: Fix race in LockBufferForCleanup()
LockBufferForCleanup() acquires the exclusive content lock, checks the
buffer's shared pin count, and, if other pins remain, registers itself
as the BM_PIN_COUNT_WAITER before waiting for an unpin notification.
Since commits 5310fac6e0f and c75ebc657ffc, however, a shared buffer
pin can be released while BM_LOCKED is set, introducing the following
race:
- LockBufferForCleanup() observes a refcount greater than one.
- Before it sets BM_PIN_COUNT_WAITER, another backend releases the
last conflicting pin.
- Since BM_PIN_COUNT_WAITER is not yet set, no wakeup is sent.
- LockBufferForCleanup() then sets BM_PIN_COUNT_WAITER and goes to
sleep, even though only its own pin remains.
As a result, LockBufferForCleanup() can sleep indefinitely because
the wakeup corresponding to the last conflicting unpin has already been
missed.
Fix this by setting BM_PIN_COUNT_WAITER while holding the buffer
header lock, then rechecking the refcount before releasing the content
lock. If only our pin remains, clear the waiter state and proceed
without sleeping. Otherwise, wait as before.
This issue was reported by buildfarm member skink, where it manifested
as intermittent timeouts in 048_vacuum_horizon_floor.pl.
Fujii Masao [Mon, 29 Jun 2026 23:48:47 +0000 (08:48 +0900)]
Fix unlogged sequence corruption after standby promotion
Previously, if an unlogged sequence was created on the primary and
replicated to a standby, reading the sequence after promoting the
standby (for example, with nextval()) could trigger the following
assertion failure:
In non-assert builds, the same operation could instead fail with an
error such as:
ERROR: bad magic number in sequence
The problem was that seq_redo() updated the init fork page in shared
buffers but did not flush it to disk. During promotion,
ResetUnloggedRelations() recreates the main fork of unlogged
relations by copying the init fork from disk, bypassing shared
buffers. As a result, the main fork could be recreated from a stale
init fork instead of the WAL-replayed page.
Fix this by introducing a helper to flush init fork buffers
immediately, and make seq_redo() use it. As a result, the main fork
of an unlogged sequence is recreated from the up-to-date init fork on
disk, allowing the unlogged sequence to be read successfully after
standby promotion.
Backpatch to v15, where unlogged sequences were introduced.
Michael Paquier [Mon, 29 Jun 2026 23:30:08 +0000 (08:30 +0900)]
Simplify some stats restore code with InputFunctionCallSafe()
statatt_build_stavalues() and array_in_safe() have been relying on
InitFunctionCallInfoData() with a locally-filled state to call a data
type input function. InputFunctionCallSafe() can be used to achieve the
same job, simplifying some code.
This fixes an over-allocation of FunctionCallInfoBaseData done in
statatt_build_stavalues(), where there was space for 8 elements but only
3 were needed. The over-allocation exists since REL_18_STABLE, and was
harmless in practice.
While on it, fix some comments for both routines, where elemtypid was
mentioned.
Backpatch down to v19. This code has been reworked during the last
development cycle while working on the restore of extended statistics,
so this keeps the code consistent across all branches.
Author: Jian He <jian.universality@gmail.com>
Author: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/CACJufxEGah9PaiTQ=cG14GMMBsUQ3ohGct9tdSwbMQPQ0-nbbQ@mail.gmail.com
Backpatch-through: 19
Peter Eisentraut [Mon, 29 Jun 2026 13:13:45 +0000 (15:13 +0200)]
Forbid FOR PORTION OF with WHERE CURRENT OF
It is not clear how the implicit condition of FOR PORTION OF should
interact with the use of a cursor. Normally, we forbid combining
WHERE CURRENT OF with other WHERE conditions. The SQL standard only
includes FOR PORTION OF with <update statement: searched> and <delete
statement: searched>, not <update statement: positioned> or <delete
statement: positioned>, so it is easy for us to exclude the
functionality, at least for now.
Author: Paul A. Jungwirth <pj@illuminatedcomputing.com>
Discussion: https://www.postgresql.org/message-id/flat/CA%2BrenyUEKPexUYsH4qeU8_o1jqKsUkEWca1keS6n21shgG1g%2BA%40mail.gmail.com
Peter Eisentraut [Mon, 29 Jun 2026 09:49:11 +0000 (11:49 +0200)]
Fix handling of copy_file_range() return value
Treat copy_file_range() return value of zero as an error: it indicates
that no bytes could be copied (perhaps the source file is shorter than
expected), and the existing retry loop would otherwise spin forever
since nwritten would never reach BLCKSZ.
The other uses of copy_file_range() in the tree don't have this
problem.
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com> Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Reviewed-by: Yingying Chen <cyy9255@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/3208cf7a-c7f3-41eb-92f6-33cbeff4df40%40eisentraut.org
Michael Paquier [Mon, 29 Jun 2026 04:15:07 +0000 (13:15 +0900)]
doc: Reorder table for Object DDL Functions
While on it, let's add links pointing to the set of SQL commands
generated by these functions. The descriptions of the functions are
exactly the same, just moved around.
Author: Peter Smith <smithpb2250@gmail.com> Reviewed-by: Ian Lawrence Barwick <barwick@gmail.com>
Discussion: https://postgr.es/m/CAHut+Pun9Z8qZFJTa9fLgdhM=Cip9d-cnx2YXDW6eFrSwbQj1g@mail.gmail.com
Richard Guo [Mon, 29 Jun 2026 02:38:39 +0000 (11:38 +0900)]
plpython: Fix NULL pointer dereferences for broken sequence and mapping objects
PL/Python and its hstore and jsonb transforms build SQL values from
Python containers by calling Python C API functions that can return
NULL, and in several places the result was used without first checking
it.
On the sequence side, PySequence_GetItem() is used when converting a
returned sequence into a SQL array or composite value, when reading
the argument list passed to plpy.execute() or plpy.cursor(), and when
reading the list of type names given to plpy.prepare(). On the
mapping side, the hstore and jsonb transforms call PyMapping_Size()
and PyMapping_Items() and then index the result with PyList_GetItem()
and PyTuple_GetItem().
All of these return NULL (or -1), with a Python exception set, for a
broken object: for example one whose __getitem__() or items() raises,
or which reports a length that disagrees with what it actually yields.
The unchecked result was then dereferenced, crashing the backend.
Fix this by checking the result of each call and reporting a regular
error if it failed, so that the underlying Python exception is
surfaced instead of taking down the session.
Amit Langote [Mon, 29 Jun 2026 01:24:28 +0000 (10:24 +0900)]
Hardwire RI fast-path end-of-xact cleanup into xact.c
Commit b7b27eb41a5, which added foreign-key fast-path batching to
ri_triggers.c, registered ri_FastPathXactCallback() via
RegisterXactCallback() to clear the fast-path batching state at end of
transaction. RegisterXactCallback() is documented as intended for
dynamically loaded modules; built-in code is supposed to hardwire its
end-of-xact hooks into xact.c, mainly so callback ordering can be
controlled where it matters (see the header comment on
RegisterXactCallback()).
Convert the callback into a plain AtEOXact_RI() function and call it
directly from CommitTransaction(), PrepareTransaction() and
AbortTransaction(), alongside the other AtEOXact_* cleanup steps, and
drop the RegisterXactCallback() registration.
Like the other AtEOXact_* routines, AtEOXact_RI() takes an isCommit
argument and treats the two paths differently. On commit or prepare
the fast-path cache must already have been flushed and torn down by
the after-trigger batch callback, so a surviving cache indicates a
trigger batch was never flushed -- which would have silently skipped
FK checks -- and draws an Assert plus a WARNING. On abort a surviving
cache is expected (a flush may have errored out partway) and is simply
reset.
There is no ordering dependency here: AtEOXact_RI() only resets
backend-local static state (the cache pointer, the
callback-registered flag, and the in-flush guard). It touches no
relations, locks, buffers or catalogs, so its position relative to
ResourceOwnerRelease() and the surrounding AtEOXact_* calls does not
matter. On a normal commit the fast-path cache has already been
flushed and torn down by ri_FastPathEndBatch() (an
AfterTriggerBatchCallback fired from AfterTriggerFireDeferred(), well
before any end-of-xact callback), so the reset is a no-op; its real
job is the abort path, where teardown may not have run and the static
pointers would otherwise dangle into the next transaction. The cache
memory itself lives in TopTransactionContext and is freed by the
end-of-transaction memory-context reset on both paths.
The companion RegisterSubXactCallback() use from b7b27eb41a5 was
already removed by commit 4113873a, which confined fast-path batching
to the top transaction level, so only the RegisterXactCallback() use
remained.
doc: Improve consistency in varlistentry attributes
Use underscores consistent across the varlistentry attributes in
config.sgml. Inconsistencies found using Claude, verified by the
reporter.
Reported-by: Bill Kim <billkimjh@gmail.com> Reviewed-by: Peter Smith <smithpb2250@gmail.com>
Discussion: https://postgr.es/m/CAMQXxchB0ZfMHyk+Ji-=s3hkqh0_XyuKiaNLRgvatvndSt3KNw@mail.gmail.com
Tom Lane [Sun, 28 Jun 2026 16:31:29 +0000 (12:31 -0400)]
Avoid collation lookup failure when considering a "char" column.
If a "char" column has a statistics histogram, scalarineqsel()
would fail with "cache lookup failed for collation 0". Avoid
the failing lookup by acting as though the collation is "C".
Prior to commit 06421b084, this code didn't fail because
lc_collate_is_c() intentionally didn't spit up on InvalidOid.
It did act differently though: it would take the non-C-collation
code path and hence apply strxfrm using libc's prevailing locale.
But that seems like the wrong thing for a non-collatable comparison,
so let's not resurrect that aspect.
Author: Feng Wu <wufengwufengwufeng@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CACK3muq6s-O1Wc3w4dRL1Fe8YQ-Fz1zJbezeQwhuLgNxGNEFiA@mail.gmail.com
Backpatch-through: 18
Andrew Dunstan [Fri, 26 Jun 2026 12:00:39 +0000 (08:00 -0400)]
Use named boolean parameters for pg_get_*_ddl option arguments
Replace the VARIADIC text[] alternating key/value option interface with
typed named boolean parameters for pg_get_role_ddl(), pg_get_tablespace_ddl(),
and pg_get_database_ddl(), as added by commit 4881981f920 and friends.
The new signatures are:
This provides type safety at the SQL level, allows named-argument calling
syntax (pretty => true), removes the runtime string-parsing machinery
(DdlOption, parse_ddl_options) in favour of direct PG_GETARG_BOOL() calls,
and allows the functions to be marked STRICT.
While we're here, I added an extra TAP test for pg_get_database(owner =>
false, ...)
Catalog version bumped.
Author: Jelte Fennema-Nio <postgres@jeltef.nl>
Discussion: https://postgr.es/m/DHM6C7SLS4BN.1WW9Z4PRPN0VJ@jeltef.nl
(and on Discord)
Andrew Dunstan [Sat, 27 Jun 2026 21:43:02 +0000 (17:43 -0400)]
doc: Clarify ALTER CONSTRAINT enforceability behavior
The ALTER TABLE documentation said that FOREIGN KEY and CHECK
constraints may be altered, but did not distinguish between
deferrability and enforceability attributes.
Clarify that deferrability attributes can currently be altered only for
FOREIGN KEY constraints, while enforceability can be altered for both
FOREIGN KEY and CHECK constraints. Also document that setting a
constraint to ENFORCED verifies existing rows and resumes checking new
or updated rows.
Andrew Dunstan [Sat, 27 Jun 2026 21:43:02 +0000 (17:43 -0400)]
doc: Clarify inherited constraint behavior
Update the table inheritance documentation to mention not-null constraints
alongside check constraints where inherited constraints are discussed.
Also clarify that some properties of inherited constraints can now be altered
directly on child tables, while the resulting constraint must remain compatible
with its inherited parent constraints. For multiple inheritance, say explicitly
that when a column or constraint is inherited from more than one parent, the
stricter definition applies.
Author: Chao Li <lic@highgo.com> Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com>
Discussion: https://postgr.es/m/E74C57FA-1DD0-4C8E-8FB1-538034752592@gmail.com
Andrew Dunstan [Sat, 27 Jun 2026 21:42:51 +0000 (17:42 -0400)]
Prevent inherited CHECK constraints from being weakened
Disallow marking an inherited CHECK constraint as NOT ENFORCED when an
equivalent parent constraint remains ENFORCED. This prevents ALTER
CONSTRAINT from producing a child constraint that is weaker than one of
its inherited parent definitions.
When recursively altering a CHECK constraint to NOT ENFORCED, collect the
corresponding constraints in the affected inheritance subtree and ignore
those parent constraints while checking descendants. If a descendant also
inherits an equivalent ENFORCED constraint from a parent outside the
current ALTER, keep the descendant ENFORCED by merging to the stricter
state.
This was missed in commit 342051d73b3, which introduced the ability to
alter CHECK constraint enforceability.
Add regression coverage for direct child ALTER, ONLY ALTER, mixed-parent
inheritance, and a common-ancestor diamond where all equivalent inherited
constraints can be changed together.
Author: Chao Li <lic@highgo.com> Reviewed-by: Jian He <jian.universality@gmail.com> Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com> Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>
Discussion: https://postgr.es/m/E74C57FA-1DD0-4C8E-8FB1-538034752592@gmail.com
Andrew Dunstan [Sat, 27 Jun 2026 20:48:35 +0000 (16:48 -0400)]
COPY TO FORMAT JSON: respect column list order
When COPY TO with FORMAT json is given an explicit column list that
names all columns in a different order, the JSON output incorrectly
used the table's physical column order instead of the requested order.
This happened because BeginCopyTo() only built a restricted TupleDesc
when list_length(attnumlist) < tupDesc->natts. When all columns are
listed (just reordered), this condition was false and no projected
TupleDesc was built, causing CopyToJsonOneRow() to emit columns in
physical order.
Fix by also building the projected TupleDesc when an explicit column
list was provided (attnamelist != NIL), even if it names all columns.
Author: Baji Shaik <baji.pgdev@gmail.com> Reviewed-by: Andrew Dunstan <andrew@dunslane.net>
Discussion: https://postgr.es/m/CA+fm-ROd4cNKM524n6EdgtZ9xOzOHJDNv8J_9Mvr2+2t1qWSDw@mail.gmail.com
Peter Eisentraut [Sat, 27 Jun 2026 17:34:40 +0000 (19:34 +0200)]
Reject child partition FDWs in FOR PORTION OF
We should defer validating FDW usage until after analysis. We have to
guard against not just the topmost table, but also individual child
partitions. Added the check to CheckValidResultRel, because it is
called after looking up child partitions (accounting for pruning), but
before the FDW can run a DirectModify update, which would bypass
per-tuple executor work.
Author: jian he <jian.universality@gmail.com> Reported-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Paul A. Jungwirth <pj@illuminatedcomputing.com>
Discussion: https://www.postgresql.org/message-id/flat/CA%2BrenyUte0_UJsJiDJQi82oaBsMJn%3Dcct0Wn%3DvOqXtuDn%3DYYJA%40mail.gmail.com
Peter Eisentraut [Sat, 27 Jun 2026 07:07:07 +0000 (09:07 +0200)]
Move FOR PORTION OF volatile check into planner
This needs to be wary of the function volatility changing after we
check it. We cannot enforce this when checking at parse time, so move
it later, into the planner.
Author: Paul A. Jungwirth <pj@illuminatedcomputing.com> Reported-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: jian he <jian.universality@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/CA%2BrenyUte0_UJsJiDJQi82oaBsMJn%3Dcct0Wn%3DvOqXtuDn%3DYYJA%40mail.gmail.com
Michael Paquier [Sat, 27 Jun 2026 02:45:56 +0000 (11:45 +0900)]
Switch maximum of GUC huge_page_size to MAX_KILOBYTES
As documented in guc.h, MAX_KILOBYTES is used to cap GUC parameters that
are measured in kilobytes of memory. This way, size_t values can fit in
builds where sizeof(size_t) is 4 bytes.
Unfortunately, huge_page_size has missed this aspect, causing
calculation failures when setting this GUC to a value higher than
MAX_KILOBYTES, up to INT_MAX.
Oversight in d2bddc2500fb. No backpatch is done, based on the lack of
complaints.
Álvaro Herrera [Fri, 26 Jun 2026 18:03:42 +0000 (20:03 +0200)]
Make crosstabview honor boolean/null display settings
psql's \pset display_true/false settings, added by commit 645cb44c5490,
affect normal query output, but not \crosstabview. As a result, boolean
values used anywhere in crosstab output were always shown as "t" or "f",
which is inconsistent. Change \crosstabview so that the configured
values are displayed instead.
While at it, make \crosstabview print the \pset null string, if any, in
cells for which the query produces a NULL value. Cells for which the
query produces no value continue to have the empty string. This is an
oversight in the aboriginal \crosstabview commit, c09b18f21c52.
Add a regression test covering all of this.
Author: Chao Li <lic@highgo.com> Reported-by: Chao Li <lic@highgo.com> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>
Backpatch: none needed
Discussion: https://postgr.es/m/B5E6F0A5-4B48-46D0-B5EB-CF8F8CC7D07D@gmail.com
Tomas Vondra [Fri, 26 Jun 2026 17:34:14 +0000 (19:34 +0200)]
Fix out-of-bounds access in autoprewarm worker
The read stream callback apw_read_stream_next_block() advances p->pos
through the block_info array. When processing the last block, it
increments p->pos to prewarm_stop_idx before returning. The callback
itself is safe because it checks bounds before accessing the array.
However, the caller assigned blk from block_info[i] at the end of the
loop body, before the loop condition was re-evaluated. When i equaled
prewarm_stop_idx, this accessed memory beyond the allocated DSM segment,
causing a segfault.
Restructure the loop to check bounds at the top and assign blk at the
beginning of the loop body, where it is always safe. This avoids the
need for an explicit bounds check at the end.
Backpatch to 18, where the bug was introduced by commit 6acab8bdbcda.
Tomas Vondra [Fri, 26 Jun 2026 15:57:26 +0000 (17:57 +0200)]
Improve docs for EXPLAIN (IO)
Commit 681daed931 introduced a new EXPLAIN option "IO", but the docs
did not explain what information was added to the output. Expand the
description a little bit, similarly to the other EXPLAIN options.
Take into account default_tablespace during MERGE/SPLIT PARTITION(S)
createPartitionTable() passed the partitioned parent's reltablespace straight
to heap_create_with_catalog(), bypassing the default_tablespace GUC fallback
that DefineRelation() applies for CREATE TABLE ... PARTITION OF. When the
parent had no explicit tablespace (reltablespace = 0), the new partition
unconditionally landed in the database default, even if default_tablespace
was set to something else; merging or splitting a set of partitions that all
lived in a non-default tablespace produced a new partition in the database
default.
Mirror DefineRelation()'s logic: take parent's reltablespace if set,
otherwise check GetDefaultTablespace() (which reads default_tablespace
and normalises pg_default / MyDatabaseTableSpace to InvalidOid). Also
add the CREATE ACL check on the resolved tablespace and the pg_global
rejection, matching DefineRelation()'s behavior.
Update the documentation for MERGE/SPLIT PARTITION to spell out the
tablespace-selection rule explicitly.
Reported-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Pavel Borisov <pashkin.elfe@gmail.com>
Discussion: https://postgr.es/m/ajQTklv8QArzTp3h%40pryzbyj2023
Michael Paquier [Fri, 26 Jun 2026 01:47:32 +0000 (10:47 +0900)]
doc: Improve description of pg_get_multixact_stats()
This addresses two gaps in the documentation:
- The function uses an xid, and was not mentioned as an exception in a
section of the docs related to xid8.
- The function returns NULL if a role does not have the privileges of
pg_read_all_stats. The execution is not denied.
Author: Chao Li <li.evan.chao@gmail.com>
Author: Yingying Chen <cyy9255@gmail.com>
Discussion: https://postgr.es/m/CAGGTb65Qmtor2nJP-ATgfWpMpD2qhKrdyO7fmRbbS++nQ=vtMw@mail.gmail.com
Masahiko Sawada [Thu, 25 Jun 2026 21:25:57 +0000 (14:25 -0700)]
Mark uuid-to-bytea cast as leakproof.
The uuid-to-bytea cast just serializes a valid uuid datum into its
fixed 16-byte representation. It does not have an input-dependent
error path so mark its pg_proc entry as leakproof.
Tom Lane [Thu, 25 Jun 2026 20:58:29 +0000 (16:58 -0400)]
Fix null-pointer crash in ECPG compiler.
When compiling a DECLARE section containing a union nested
inside a struct, ecpg passes a null value for struct_sizeof to
ECPGmake_struct_type. I (tgl) didn't foresee that case in
commit 0e6060790, and wrote an unprotected mm_strdup() call.
Reported-by: iMSA (via Jehan-Guillaume de Rorthais <jgdr@dalibo.com>)
Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/20260625114849.34b2148e@karst
Backpatch-through: 18
Melanie Plageman [Wed, 24 Jun 2026 18:51:31 +0000 (14:51 -0400)]
pg_stat_io: Don't flag extends by autovacuum launcher
pg_stat_io asserts on unexpected combinations of backend type and IOOp.
These combinations were meant to help detect bugs given our current
understanding of the system -- not serve as a set of rules for what is
allowed. The autovacuum launcher scans catalog tables and may on-access
prune them. This previously wouldn't have led to any extends of the
relation, but now that on-access pruning may pin a page of the
visibility map (4f7ecca84ddacbce27), scanning tables may lead to
extending the visibility map. This would cause the launcher to trip an
assert. Since there is no reason to forbid the launcher from doing
extends, remove it from the list of backend type pgstat_tracks_io_op
flags for doing IOOP_EXTEND.
Read-only catalog scans still don't let pruning set the VM; doing so
needs table AM API changes and is left for the future.
Reported-by: Ewan Young <kdbase.hack@gmail.com>
Discussion: https://postgr.es/m/CAON2xHNOyaN9MCZohhD_NL6as3QVhGA0SOn2Hyi9w6+Y-_1bFA@mail.gmail.com
Fujii Masao [Wed, 24 Jun 2026 13:57:50 +0000 (22:57 +0900)]
psql: Add tab completion for subscription wal_receiver_timeout
Commit fb80f388f added wal_receiver_timeout as a CREATE/ALTER
SUBSCRIPTION option, but psql tab completion did not include it in the
subscription option lists.
Add wal_receiver_timeout to completion for CREATE SUBSCRIPTION ... WITH
and ALTER SUBSCRIPTION ... SET.
Distinguish datacheckums worker invocations more reliably
In some corner cases, a new datachecksums worker could be launched
while an old one was still running. If you're really unlucky, the old
worker could set the worker_result in shared memory and mislead the
launcher to think that a newer worker invocation completed
successfully, even though it failed for some reason. That's highly
unlikely to happen in practice as it requires several race conditions
with workers and launchers starting, failing and succeeding and at the
right moments. Nevertheless, better to tighten it up.
To distinguish different worker invocations, assign a unique
'worker_invocation' number every time a new worker is launched. In
the worker, check that the invocation number matches before setting
the worker result. This ensures that the result always belongs to the
latest invocation.
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://www.postgresql.org/message-id/b283fbb9-298e-4953-9120-eefaf24fae20@iki.fi
Minor cleanup around checking datachecksum worker result
Rename the 'success' field in DataChecksumState to 'worker_result'.
That's more appropriate when it's not a simple boolean.
Don't access the field after releasing the lock in ProcessDatabase().
No other process should be modifying it, but if we bother to do any
locking in the first place, let's do it right.
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://www.postgresql.org/message-id/b283fbb9-298e-4953-9120-eefaf24fae20@iki.fi
Avoid leaving DataChecksumState->worker_pid to an old value
It might be left to an old value if the launcher was terminated while
a worker was running. launcher_exit() sends SIGTERM to the worker,
but did not clear 'worker_pid'. Clear it, to be tidy.
Also clear it in ProcessDatabase() before starting a new datachecksums
worker, to be sure we start from a clean slate. The codepath where
WaitForBackgroundWorkerStartup() returns BGWH_STOPPED but
worker_result != DATACHECKSUMSWORKER_SUCCESSFUL didn't clear it, while
all other codepaths did clear or set it.
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://www.postgresql.org/message-id/b283fbb9-298e-4953-9120-eefaf24fae20@iki.fi
Move DataChecksumsWorkerResult struct to the .c file. It's not used
anywhere else since commit 07009121c2 removed the injection point test
code that the comment referred to.
Mark StartDataChecksumsWorkerLauncher() as static, since it's not
called from outside the .c file. The DataChecksumsWorkerOperation
struct can then be moved into the .c file too.
Clarify the comment on StartDataChecksumsWorkerLauncher(). It said
"Main entry point for datachecksumsworker launcher process", but I
found that misleading. That description would be a better fit for
DataChecksumsWorkerLauncherMain(), which is the process's "main"
function, rather than StartDataChecksumsWorkerLauncher().
Fix comment on WaitForAllTransactionsToFinish() on postmaster death.
The comment claimed that it sets "the abort flag" on postmaster death,
but it actually just errors outs. Improve the comment to explain why
it doesn't just use WL_EXIT_ON_PM_DEATH.
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://www.postgresql.org/message-id/b283fbb9-298e-4953-9120-eefaf24fae20@iki.fi
Michael Paquier [Wed, 24 Jun 2026 07:00:28 +0000 (16:00 +0900)]
Fix set of typos and grammar mistakes
This is similar to d3bba0415435, batching all the reports of this type
received since the last batch. This covers typos and inconsistencies
for the most part.
The user-visible documentation change impacts only HEAD.
projects / thirdparty / postgresql.git / log
