Michael Paquier [Fri, 12 Jun 2026 01:25:45 +0000 (10:25 +0900)]
Fix handling of namespace nodes in xpath() (xml)
xpath() attempted to call xmlCopyNode() and xmlNodeDump() on a
XML_NAMESPACE_DECL, finishing with a confusing error:
=# SELECT xpath('//namespace::foo', '<root xmlns:foo="http://127.0.0.1"/>');
ERROR: 53200: could not copy node
CONTEXT: SQL function "xpath" statement 1
xpath() is changed so as it goes through xmlXPathCastNodeToString()
instead, that is able to handle namespace nodes. xml2 uses the same
solution. This issue has been discovered while digging into 9d33a5a804db.
Author: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/aioT7ui_ZJ9RMlfM@paquier.xyz
Backpatch-through: 14
When amcheck validates that a B-Tree metapage's allequalimage flag
matches _bt_allequalimage(), it could fail to report corruption
unless one of the index key columns used interval_ops. As a result,
pg_amcheck could silently miss this corruption on other opclasses,
incorrectly reporting the index as valid.
The mistake was that bt_index_check_callback() kept ereport(ERROR)
inside the loop that scans key attributes for INTERVAL_BTREE_FAM_OID,
even though that loop is only needed to decide whether to add
the interval-specific hint. This commit moves ereport() out of the loop
so allequalimage mismatches are always reported, while still emitting
the hint for affected interval indexes.
Back-patch to v18, where d70b17636dd introduced this regression
while moving the check into bt_index_check_callback().
Fujii Masao [Thu, 11 Jun 2026 23:32:39 +0000 (08:32 +0900)]
Fix md5_password_warnings for role and database settings
MD5 authentication warnings are queued during authentication, before
startup options and role/database settings have been applied. The code
checked md5_password_warnings at queue time, so settings such as
ALTER ROLE ... SET md5_password_warnings = off did not suppress the
warning, even though the established session showed the GUC as off.
Keep the connection-warning infrastructure generic by allowing each
queued warning to carry an optional filter callback. Evaluate that
callback when warnings are emitted, after startup options and
role/database settings have been processed.
Use this for MD5 authentication warnings, while leaving password
expiration warnings unchanged. Add test coverage for an MD5-authenticated
role with md5_password_warnings disabled.
Author: Chao Li <lic@highgo.com> Reviewed-by: Japin Li <japinli@hotmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Discussion: https://postgr.es/m/AE46E42D-5966-4D76-9E64-95EAB01B9FB5@gmail.com
Robert Haas [Thu, 11 Jun 2026 19:55:44 +0000 (15:55 -0400)]
Fix type confusion in AddRelsyncInvalidationMessage
Since this is trying to add a SharedInvalRelSyncMsg rather than
a SharedInvalRelcacheMsg, it should use rs rather than rc.
This makes no difference as things stand, because the two structure
definitions are identical (except for the capitalization of "relid"),
but it's still a good idea to fix it.
Co-authored-by: Stolpovskikh Danil <d.stolpovskikh@ftdata.ru> Co-authored-by: Robert Haas <rhaas@postgresql.org>
Discussion: http://postgr.es/m/bd6a5735b72b4afe99af49c3c62901d6@localhost.localdomain
Álvaro Herrera [Thu, 11 Jun 2026 16:29:36 +0000 (18:29 +0200)]
Fix translatable string construction
In a few places, we were constructing translatable strings consisting of
elements list by adding one element at a time and separately a comma.
This is not great from a translation point of view, so rewrite to append
the comma together with the corresponding element in one go.
Author: Peter Smith <smithpb2250@gmail.com>
Author: Álvaro Herrera <alvherre@kurilemu.de>
Discussion: https://postgr.es/m/CAHut+Pvp7jYcaiZ3pXedXgLcWZWDBLXFUK05JtZpGv3Mj=UOjw@mail.gmail.com
Álvaro Herrera [Thu, 11 Jun 2026 14:17:58 +0000 (16:17 +0200)]
IS JSON/JSON(): Protect against expressions uncoercible to text
transformJsonParseArg() was not careful enough on generation of
transformed expressions when starting from expressions that are not
coercible to text but are in the string type category: it failed to
verify that coerce_to_target_type() succeeds, and returned a NULL
pointer. This leads to a later NULL dereference and crash at executor
time.
This escaped noticed because it cannot happen for built-in types, all of
which have casts to text. Only user-created types are potentially
problematic.
Fix by raising an error when a cast to text doesn't exist.
Dean Rasheed [Thu, 11 Jun 2026 11:08:47 +0000 (12:08 +0100)]
Fix parsing of parenthesised OLD/NEW in RETURNING list.
When parsing expressions like (old).colname and (old).* in a RETURNING
list, the parser would lose track of the intended varreturningtype,
and therefore return incorrect results.
The root cause was code using GetNSItemByRangeTablePosn() to find a
namespace item from its rtindex and levelsup, without taking into
account returningtype, which would return the wrong namespace item.
Fix by adding a new function GetNSItemByVar() that does take
returningtype into account.
Backpatch to v18, where support for RETURNING OLD/NEW was added.
Bug: #19516 Reported-by: Marko Grujic <markoog@gmail.com>
Author: Marko Grujic <markoog@gmail.com> Suggested-by: Dean Rasheed <dean.a.rasheed@gmail.com> Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>
Discussion: https://postgr.es/m/CAOvwyF2cO_5mAt=w=y-dFnaG5UkZ+3H8nSDoKF_iuWZHsU2ARg@mail.gmail.com
Backpatch-through: 18
seg: Fix seg_out() to preserve the upper boundary's certainty indicator
When printing the upper boundary of a seg interval, seg_out() decided
whether to emit the certainty indicator ('<', '>' or '~') by testing the
upper indicator (u_ext) for '<' and '>', but mistakenly tested the lower
indicator (l_ext) for '~'. This is a copy-and-paste slip from the
symmetric code that prints the lower boundary a few lines above.
The consequences for valid input were:
* A '~' on the upper boundary was dropped on output, e.g.
'1.5 .. ~2.5'::seg printed as '1.5 .. 2.5'.
* When the lower boundary carried '~' but the upper boundary had no
indicator, the wrong test matched and sprintf(p, "%c", seg->u_ext)
wrote a NUL byte (u_ext == '\0'), which truncated the result string
and silently lost the entire upper boundary, e.g.
'~6.5 .. 8.5'::seg printed as '~6.5 .. '.
Certainty indicators are documented to be preserved on output (they are
ignored by the operators, but kept as comments), so this broke the
input/output round-trip for the affected values.
The bug has existed since seg was added. It went unnoticed because the
existing regression tests only exercised certainty indicators on
single-point segs, which are printed by a different branch of seg_out().
Add tests that place indicators on both boundaries of an interval.
Author: Ewan Young <kdbase.hack@gmail.com>
Discussion: https://www.postgresql.org/message-id/CAON2xHPYeRRCEVAv8XfE18KsEsEHCiYcJ5fOsoxFuMEfpxF1=g@mail.gmail.com
Backpatch-through: 14
Michael Paquier [Thu, 11 Jun 2026 08:28:57 +0000 (17:28 +0900)]
Fix race with timeline selection in logical decoding during promotion
During promotion, there is a window where RecoveryInProgress() returns
true but the WAL segments of the old timeline have already been removed.
A logical decoding could pick up the old timeline in this window when
reading a page, failing with the following error:
ERROR: requested WAL segment ... has already been removed
This issue does not lead to any data correctness issue, as retrying to
decode the data works in follow-up decoding attempts. It impacts
availability, though. Other WAL page read callbacks have a similar
issue, this commit takes care of what should be the noisiest code path:
logical decoding with START_REPLICATION in a WAL sender.
A TAP test, based on an injection point waiting in the startup process
after the segments have been removed/recycled, is added. This part is
backpatched down to v17.
This issue has been causing sporadic failures in the buildfarm, and
was reproducible manually. This issue happens since logical decoding on
standbys exists, down to v16.
Amit Kapila [Thu, 11 Jun 2026 05:47:54 +0000 (11:17 +0530)]
Disallow negative values for max_retention_duration.
The subscription option max_retention_duration accepts an integer value
representing a timeout in milliseconds, where zero means unlimited
retention (no timeout). Negative values have no useful meaning, but were
silently accepted and stored in the subscription catalog.
A negative value causes should_stop_conflict_info_retention() to always
return true, because TimestampDifferenceExceeds() treats a negative
threshold as already exceeded. This stops dead tuple retention
immediately rather than honoring the configured timeout.
Fix by rejecting negative values for max_retention_duration during CREATE
SUBSCRIPTION and ALTER SUBSCRIPTION.
Author: Chao Li <lic@highgo.com> Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
Discussion: https://postgr.es/m/9232401A-DEEE-49E1-9D11-D14A776DB82B@gmail.com
Michael Paquier [Thu, 11 Jun 2026 05:29:18 +0000 (14:29 +0900)]
xml2: Fix crash with namespace nodes in xpath_nodeset()
pgxmlNodeSetToText() passed nodeTab[i]->doc to xmlNodeDump() without
checking the node type, which could cause a crash as a
XML_NAMESPACE_DECL maps to a xmlNs struct. The passed-in code would
then be dereferenced in xmlNodeDump().
This commit switches the code to render XML_NAMESPACE_DECL nodes with
xmlXPathCastNodeToString(), like xpath_table(). Some tests are added,
written by me.
In pursuit of removing a Valgrind-detected leak, I inserted
"pfree(pq_mq_handle);" into mq_putmessage's recursion-trouble-recovery
code path, failing to notice that shm_mq_detach would have pfree'd
that block just before (i.e., this particular code path did not leak).
So now that was a double pfree. We didn't notice because the
recursion scenario isn't exercised in our regression tests, but
Alexander Lakhin found it via code fuzzing.
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/b8b40954-e155-41b3-9af8-ad4f261a1b64@gmail.com
Michael Paquier [Wed, 10 Jun 2026 04:49:26 +0000 (13:49 +0900)]
Fix MarkBufferDirtyHint() to not call GetBufferDescriptor() for local buffers
GetBufferDescriptor() was called before checking if the buffer is local.
Such buffers have a negative ID, meaning that we could call
GetBufferDescriptor() with a wrapped-around uint32 value causing a
potential out-of-bound access to the BufferDescriptors array.
This is harmless in the existing code for the current uses of
MarkBufferDirtyHint(), but the author has found a way to make that
buggy while working on a different patch set, and the order of the
operations is wrong.
Oversight in 82467f627bd4. No backpatch is required, as this is new to
v19.
Fujii Masao [Wed, 10 Jun 2026 03:32:59 +0000 (12:32 +0900)]
pg_buffercache: restore rowtype verification in pg_buffercache_pages()
Commit 257c8231bf9 changed pg_buffercache_pages() to materialize its output
directly into a tuplestore. As a result, the function ended up trusting
a caller-supplied RECORD descriptors. That could lead to crashes
if the supplied row definition did not match the actual returned values,
for example by passing bool Datums to tuplestore_putvalues() with
an incompatible descriptor.
Fix this by constructing the correct tuple descriptor for
pg_buffercache_pages() and assigning it to
rsinfo->setDesc after InitMaterializedSRF(). This restores the executor's
tupledesc_match() verification, so incompatible caller-supplied
row definitions are rejected with an error, as before commit 257c8231bf9.
Masahiko Sawada [Tue, 9 Jun 2026 18:19:27 +0000 (11:19 -0700)]
Fix race when logical decoding activation is concurrently interrupted.
EnableLogicalDecoding() sets xlog_logical_info to true, emits a
procsignal barrier, sets logical_decoding_enabled to true, and then
writes a WAL record. If the activating backend is interrupted between
these steps, a PG_ENSURE_ERROR_CLEANUP() callback runs to undo the
partial activation.
The previous callback asserted that logical_decoding_enabled was still
false and then cleared xlog_logical_info. Both actions were unsafe
when a second backend was concurrently activating: the peer backend
might have already observed xlog_logical_info as true, set
logical_decoding_enabled to true, and written the activation WAL
record before our callback fired, causing the first backend to hit the
assertion failure.
Fix this by having the abort callback call
RequestDisableLogicalDecoding(), allowing the checkpointer to undo the
partial activation in the same manner as a normal deactivation. This
simplifies the logic by unifying the activation abort and deactivation
paths. While this approach now wakes up the checkpointer when an
activation is interrupted, this should not be a serious issue in
practice since such interruptions are rare.
Add a test case to 051_effective_wal_level.pl.
Reported-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com>
Discussion: https://postgr.es/m/788B5B8A-BC22-48D8-818E-7B00416CF84E@gmail.com
Álvaro Herrera [Tue, 9 Jun 2026 18:12:55 +0000 (20:12 +0200)]
Disallow direct use of the pgrepack logical decoding plugin
Nothing is to be gained from using pgrepack outside of REPACK
(CONCURRENTLY), and it leads to assertion failures in assertion-enabled
builds, and to crashes due to bogus memory lifetime in production
builds. Reject attempts to do that with a clean error report.
Clean up the nearby code a tad while at it. The only functional changes
in that are that the output_writer_private context is allocated and
partially filled by the pgrepack output plugin; and that ->relid therein
is now always present (rather than only in assertion-enabled builds).
Other than that it's just minor code rearrangement and added comments.
Record dependencies on graph labels and properties
A view definition with GRAPH_TABLE depends upon the property graph it
references as well as the properties and labels referenced in it. We
recorded the dependency on the property graph, but did not record
dependency on labels and properties. This allowed properties or
labels referenced by a view to be dropped, resulting in a cache lookup
error when such a view was accessed. Fix this bug by handling
GraphPropertyRef and GraphLabelRef in find_expr_references_walker().
The dependency on the data type of property does not need to be
recorded separately as it is recorded indirectly via a dependency on
the property graph property itself.
Note that a property or a label associated with individual elements
can still be dropped as long as there are other elements that are
associated with that property or label, since they do not lead to
dropping the property or the label from the property graph altogether.
Fujii Masao [Mon, 8 Jun 2026 23:18:41 +0000 (08:18 +0900)]
Use correct type for catalog_xmin
Commit 85c17f6 mistakenly declared a variable storing catalog_xmin as
XLogRecPtr, even though catalog_xmin is a TransactionId.
This caused no functional issue, but the type was clearly incorrect.
Therefore, this commit fixes it to use the correct type TransactionId
instead, and backpatch to v17 where the issue was introduced.
Andres Freund [Mon, 8 Jun 2026 19:26:47 +0000 (15:26 -0400)]
ci: Improve ccache handling
There previously were a number of issues:
- We'd upload the cache even if we already had a high hit rate. That means we
churn through the available cache space very quickly.
For this we now check if the cache hit ratio is already high, and skip
uploading a new cache in that case.
- We'd generate per-branch caches, even if master's already would suffice,
because the branch doesn't change much
This is solved indirectly by the above.
- The cache key allowed prefix matches based on the branch,
e.g. master-pending would always use master's branch
Replace the cache key element separator of - with :, which is not a valid
part of a branch name.
- When rebasing a feature branch, we'd start with just that branch's cache,
rather than also having the newer cache of master available
This is solved by downloading by master's and the feature branch's cache,
simply overlaying both. That's possible because ccache is content addressed.
- The size of a cache would increase to the max, even though there likely will
be no benefit from old cache entries.
Address this by explicitly evicting old data and also recompressing the
cache before uploading it.
In my testing this utilizes the available cache space (10GB for personal
accounts) much more effectively than before.
The not entirely trivial determination of whether it's worth uploading a cache
entry is moved to a python script. I first had it as shell, but that gets
awkward. This way it'd also be more viable to use ccache for msvc at some
point.
The per-job redundancies are a bit annoying. There's a way around that, by
using composite actions, but I think that might be harder to understand,
without all that much of an improvement.
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>
Discussion: https://postgr.es/m/7eugqon2ilnaq6yimtq7prtl5wlia43mhpmwlydzlw4u4wonaz@hh2fagz5bjuu
Tom Lane [Mon, 8 Jun 2026 19:23:48 +0000 (15:23 -0400)]
Remove inappropriate translation marker in getObjectIdentityParts().
Strings built by this function are not supposed to be subject to
NLS translation, but commit 6566133c5 missed that memo, so that
object identities like "membership of role %s in role %s" were
translated.
Jeff Davis [Mon, 8 Jun 2026 18:47:53 +0000 (11:47 -0700)]
dict_synonym.c: remove incorrect outlen.
Previously, outlen was miscalculated if case_sensitive was false and
str_tolower() changed the byte length of the string. If outlen was too
large, pnstrdup() would stop at the NUL terminator, preventing
overrun. But if outlen was too small, it would cause truncation.
Fix by just removing outlen. It was only used in a single site, which
could just as well use pstrdup().
The change failed with an empty table and an invalid default, and the
best way to deal with that will involve an addition to the TAM API, so
it's not ready for relese 19 now.
Álvaro Herrera [Mon, 8 Jun 2026 17:49:54 +0000 (19:49 +0200)]
Fix syslogger NULL-pointer-dereference in EXEC_BACKEND
Commit 0c8e082fba8d changed the time at which MyBackendType is assigned,
breaking a careful choreography in syslogger to decide when to write
messages to its own log files. Fix by flipping a boolean at the
(approximate) location where previously MyBackendType was set, instead
of depending on MyBackendType directly.
Author: Álvaro Herrera <alvherre@kurilemu.de> Reported-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Euler Taveira <euler@eulerto.com> Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/ahP-JT4ZRPyobnLb@paquier.xyz
ExecForPortionOfLeftovers() assumed that any result relation with
ri_RootResultRelInfo should reinsert temporal leftovers through the
root relation. That is correct for partitioned tables, where tuple
routing is needed, but it is wrong for plain inheritance.
When UPDATE/DELETE FOR PORTION OF is run on an inheritance parent and
a child row is split, the leftover rows must be inserted back into the
child relation. Reinserting through the parent can lose child-only
columns and place the leftover rows in the wrong relation.
Fix this by distinguishing partitioned-table routing from plain
inheritance. For partitioned tables, keep using the root leftover
slot and insert through the root relation. For plain inheritance
children, use a leftover slot matching the child relation and insert
directly into the child. Also keep translating the application-time
column attno for child relations, so multiple-inheritance cases with
different attribute numbers are handled correctly.
Added an ExecInitForPortionOf function to set up the ForPortionOfState
for each child table, which keeps most of these decisions localized
instead of spread out through ExecForPortionOfLeftovers. Incidentally
clarified a comment about the rangetype stored in ForPortionOfState.
Add regression tests for UPDATE and DELETE FOR PORTION OF on
inheritance children, including a multiple-inheritance case where the
range column has a different attnum in the parent and child.
Author: jian he <jian.universality@gmail.com> Co-authored-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Paul A. Jungwirth <pj@illuminatedcomputing.com>
Discussion: https://www.postgresql.org/message-id/flat/4245F94D-84F1-4E05-BF81-C458A6CF9901%40gmail.com
Tom Lane [Mon, 8 Jun 2026 15:48:07 +0000 (11:48 -0400)]
Fix missed checks for hashability of container-type equality.
The operators for array_eq, record_eq, range_eq, and multirange_eq
are all marked oprcanhash, but there's a pitfall: their hash functions
can fail at runtime if the contained type(s) are not hashable.
Therefore, the planner has to check hashability of the contained types
before deciding it can use hashing in these cases. Not every place
had gotten this memo, and noplace at all had considered the issue
for ranges or multiranges. In particular we could attempt to use
hashing for a ScalarArrayOpExpr on a container type when it won't
actually work, leading to "could not identify a hash function ..."
runtime failures.
For the most part we should fix this in the lookup functions provided
by lsyscache.c, to wit get_op_hash_functions and op_hashjoinable.
But there's a problem: get_op_hash_functions is not passed the input
data type it would need to check. We mustn't change the API of that
exported function in a back-patched fix, and even if we wanted to,
its call sites in the executor mostly don't have easy access to the
required data type OID. Fortunately, the executor call sites don't
actually need fixing, because it's expected that the planner verified
hashability before building a plan that requires it. Therefore,
leave get_op_hash_functions as-is and invent a wrapper function
get_op_hash_functions_ext that does the additional checking needed
in the planner's uses.
We also need to fix hash_ok_operator (extending the fix in 647889667).
While at it, neaten up a couple of places in lookup_type_cache where
relevant code for multirange cases was written differently from the
code for other container types.
Note: while this touches pg_operator.dat, it's only to add oid_symbol
macros. So there's no on-disk data change and no need for a
catversion bump.
Reported-by: Andrei Lepikhov <lepihov@gmail.com>
Author: Andrei Lepikhov <lepihov@gmail.com> Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/ed221f95-f09b-4a9c-b05b-e1fed621ec87@gmail.com
Backpatch-through: 14
Nathan Bossart [Mon, 8 Jun 2026 15:33:52 +0000 (10:33 -0500)]
doc: Expand on proper use of refint.
The security team has received a couple of reports about potential
SQL injection via refint's trigger arguments. We discussed this
while preparing CVE-2026-6637 and concluded that forcibly quoting
these arguments is more likely to break working code than to
prevent exploits. Unlike data values, the table/column names come
from trigger arguments, and there is little reason for a trigger
author to put hostile inputs into those arguments. So, let's
document it accordingly.
Reported-by: Nikolay Samokhvalov <nik@postgres.ai> Reported-by: Alex Young <alex000young@gmail.com> Reported-by: Satyanarayana Narlapuram <satyanarlapuram@gmail.com> Suggested-by: Noah Misch <noah@leadboat.com> Reviewed-by: Noah Misch <noah@leadboat.com> Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com> Reviewed-by: Christoph Berg <myon@debian.org> Reviewed-by: Satyanarayana Narlapuram <satyanarlapuram@gmail.com>
Discussion: https://postgr.es/m/ahXP7z7nsfGPOZ3T%40nathan
Backpatch-through: 14
Fixing incorrect spelling and breaking up a long sentence.
Author: Daniel Gustafsson <daniel@yesql.se> Reported-by: Thom Brown <thom@linux.com>
Discussion: https://postgr.es/m/CAA-aLv5pZNZbdhPG2Wu0fzyKCjn9TTzN9QZ=JONPyqZQKhBV=g@mail.gmail.com
Fujii Masao [Mon, 8 Jun 2026 08:07:48 +0000 (17:07 +0900)]
ecpg: Reject multiple header items in GET/SET DESCRIPTOR
Previously, ecpg accepted multiple descriptor header items in GET DESCRIPTOR
and SET DESCRIPTOR, but generated broken C code when they were used.
Although the grammar allowed this syntax, the implementation did not actually
support it.
This commit tightens the ecpg grammar so the header form of GET/SET DESCRIPTOR
accepts only a single header item, matching the implementation and preventing
generation of broken C code.
Also update the documentation synopsis accordingly.
Amit Kapila [Mon, 8 Jun 2026 06:49:29 +0000 (12:19 +0530)]
pg_createsubscriber: Fix duplicate publication name rejection.
pg_createsubscriber rejected duplicate --publication values while parsing
command-line options, even when the duplicate names referred to
publications in different databases. Since publication names are
database-local objects, the same name is perfectly valid across multiple
databases.
This restriction was not a practical problem before commit 85ddcc2f4c,
which added support for reusing pre-existing publications. After that
change, users who have identically-named publications in multiple
databases (a common convention) could not use the feature without renaming
their publications.
The analogous restriction on --subscription names is intentionally kept as
they are reused as replication slot names, which are cluster-global, so
allowing duplicate subscription names without additional guards could
cause a slot-name collision. That work is left for a future release.
Author: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Shlok Kyal <shlok.kyal.oss@gmail.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>
Discussion: https://postgr.es/m/B08A7C89-B3DE-4C1D-A671-32AD8BAB7E22@gmail.com
Michael Paquier [Mon, 8 Jun 2026 06:29:16 +0000 (15:29 +0900)]
Fix memory leak in pgstat_progress_parallel_incr_param()
When called from a parallel worker, this function calls initStringInfo()
and pq_beginmessage(), causing a StringInfo allocation to happen twice.
pq_endmessage() frees only the second allocation, with each call leaking
~1 kB into the per-worker memory context. This could cause a few
hundred megabytes worth of memory to pile up until the worker exits (the
message allocations happen in the parallel worker context), with the
situation being worse the longer a parallel worker runs.
Michael Paquier [Mon, 8 Jun 2026 05:37:51 +0000 (14:37 +0900)]
psql: Fix expanded aligned output
When a table's columns are narrower than the record header line, the
expanded aligned format produced misaligned output because the data
column width was not adjusted to match the record header width, leading
to output like:
+-[ RECORD 1 ]-+
| a | 10 |
| b | 20 |
+---+----+
This commit adjusts the output so as the column width match with the
header line, giving:
+-[ RECORD 1 ]-+
| a | 10 |
| b | 20 |
+---+----------+
Author: Pavel Stehule <pavel.stehule@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com>
Discussion: https://postgr.es/m/CAFj8pRCzGpsr9zTHbtTd4mGh2YPJqOEgLgt8JLiopuYA9_1xGw@mail.gmail.com
Backpatch-through: 14
Amit Kapila [Mon, 8 Jun 2026 05:29:05 +0000 (10:59 +0530)]
Fix publisher retain_dead_tuples check when also changing origin.
In AlterSubscription(), when the SET clause includes both
retain_dead_tuples and origin options, the origin branch was using
assignment (=) rather than bitwise-or assignment (|=) when setting
check_pub_rdt. This meant that if retain_dead_tuples had already set the
flag to true in the same command, the origin branch would silently
overwrite it. As a result, the publisher-side retain_dead_tuples check
could be incorrectly skipped.
Fix by changing the assignment to |= so that the flag accumulates across
both option branches within the same ALTER SUBSCRIPTION command.
David Rowley [Sat, 6 Jun 2026 04:45:29 +0000 (16:45 +1200)]
Fix tuple deforming with virtual generated columns
TupleDescFinalize() failed to take into account virtual generated
columns, which are always stored as NULL in tuples. TupleDescFinalize()
didn't check for this, and that could result in attcacheoff being set for
and beyond virtual generated columns. Also, the TupleDesc's
firstNonGuaranteedAttr could also be set incorrectly, which could result
in the tuple deformation function deforming without checking for NULLs,
and deforming using incorrectly cached offsets.
This could result in tuples being deformed incorrectly, which could
result in incorrect results, ERRORs or possibly a crash.
Michael Paquier [Fri, 5 Jun 2026 23:16:36 +0000 (08:16 +0900)]
pg_surgery: Fix off-by-one bug with heap offset
heap_force_common() declared a boolean array indexed with an
OffsetNumber for a size of MaxHeapTuplesPerPage. OffsetNumbers are
1-based, so an input TID whose offset number equals MaxHeapTuplesPerPage
wrote one byte past the end of the stack array, crashing the server.
Like heapam_handler.c, this commit changes the array so as it uses a
0-based index, substracting one from the OffsetNumbers.
Document that OAuth validators can return an authenticated identity
in the authn_id member. The server records the identity value before
checking if the connection is authorized, so it may appear in
connection-authentication logs (even if the connection later fails
authorization).
Also remove outdated wording saying that all result parameters are
ignored when a validator returns false since validators may provide
error_detail.
Patch by Chao Li with some additional wordsmithing by me.
Author: Chao Li <lic@highgo.com> Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com> Reported-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://postgr.es/m/0281836A-F5FF-41A5-9EE1-656C1FAAC6B2@gmail.com
doc: Use groups instead of curves in TLS documentation
With TLS 1.3 the concept of curves was renamed to groups. Update
our wording to use groups instead of curves to make it clear what
the underlying GUC can support.
This was extracted from a slightly larger patch which also renamed
variables to match the new terminology. Given that we are in beta
this portion was however left as a future excercise.
Author: Evan Si <evsi@amazon.com> Reviewed-by: Ewan Young <kdbase.hack@gmail.com>
Discussion: https://postgr.es/m/23C40DD6-1C47-46FC-A746-8A1D8530AD3E@amazon.com
Backpatch-through: 18
Nathan Bossart [Fri, 5 Jun 2026 17:08:05 +0000 (12:08 -0500)]
refint: Remove plan cache.
Presently, refint stores plans in a per-backend cache to avoid
re-preparing in each call. This has a few problems. For one,
check_foreign_key() embeds the new key values in its cascade-UPDATE
queries, so a cached plan reuses the values from preparation.
Also, the cache is never invalidated, so it can return stale
entries that cause other problems. There may very well be more
bugs lurking.
We could spend a lot of time trying to address all these problems,
but this module is primarily intended as sample code, and by all
indications, it sees minimal use. Furthermore, there is a growing
consensus for removing refint in v20. However, since we'll need to
support it on the back-branches for a while longer, it probably
still makes sense to fix some of the more egregious bugs.
Therefore, let's just remove refint's plan cache entirely. That
means we'll re-prepare on every call, but that seems quite unlikely
to bother anyone. On v17 and older versions, the regression test
for triggers fails after this change, so I've borrowed pieces of
commit 8cfbdf8f4d to fix it.
The message sent to pg_stat_activity when waiting for transactions to
end was long enough that it could get truncated when the xid included
in the string grew large. Fix by rewording to avoid truncation, using
a similar message in the logical replication code as inspiration.
Author: Daniel Gustafsson <daniel@yesql.se> Reported-by: ChangAo Chen <cca5507@qq.com>
Discussion: https://postgr.es/m/tencent_47CA9CE2F91FF4D81D875E162AD69AA4900A@qq.com
Fix LATERAL references in GRAPH_TABLE with multi-label pattern
When rewriting a GRAPH_TABLE into a subquery,
replace_property_refs_mutator() bumps levelsup of lateral references
by one so that they reference outside the subquery. This works for
path patterns that result in only one path query. Patterns that
produce multiple path queries are rewritten as a UNION of path
queries. Since every path query becomes a subquery of the UNION
statement, the levelsup of lateral references in those path queries
need an additional bump. This adjustment was missing resulting in the
lateral references being interpreted as references in the UNION query
itself. This caused different symptoms like a crash in
create_lateral_join_info() or error "plan should not reference
subplan's variable". The symptoms varied depending on the number of
RangeTblEntries in the UNION statement.
Handle element label and label property objects in object address functions
getObjectTypeDescription() and getObjectIdentityParts() do not handle
objects in pg_propgraph_element_label and pg_propgraph_label_property
catalogs. These functions when called for handling DDL that affects
these objects cause an "unsupported object class" error. An error is
reported when these functions are called via pg_identify_object() and
pg_identify_object_as_address() with objects from the said catalogs.
The objects in these catalogs do not have a (user-given) name but they
can be manipulated individually through ALTER PROPERTY GRAPH
sub-commands. Hence they need to be accessible to the event triggers.
Handle these catalogs in the respective functions.
Michael Paquier [Fri, 5 Jun 2026 05:29:27 +0000 (14:29 +0900)]
xml2: Fix stylesheet document leak in xslt_process()
xslt_process() parses the stylesheet text into an xmlDoc before passing it
to xsltParseStylesheetDoc(). On success, the returned stylesheet owns
that document and frees it through xsltFreeStylesheet(), calling
xmlFreeDoc() at its end. On failure, libxslt leaves the caller
responsible for the xmlDoc. In xml2, this would cause the memory
allocated for the xmlDoc to pile up across calls of xslt_process() when
failing to create a sheet.
While on it, I have double-checked the code of xml2 with libxslt, and it
seems that we are in the clear now, hopefully.. This leak exists for a
long time. 732061150b0 has made the fix introduced in this commit
easier to implement.
Fujii Masao [Fri, 5 Jun 2026 00:51:55 +0000 (09:51 +0900)]
Fix pg_subscription column privileges for subwalrcvtimeout
The subwalrcvtimeout column was added by commit fb80f38, but the
column-level privileges on pg_subscription were not updated. As a
result, non-superusers cannot read the column, unlike the other
publicly readable pg_subscription columns.
This commit grants SELECT privilege on subwalrcvtimeout to PUBLIC.
Michael Paquier [Thu, 4 Jun 2026 22:50:08 +0000 (07:50 +0900)]
Fix off-by-one with NFC recomposition for Hangul U+11A7 (TBASE)
The NFC recomposition incorrectly included TBASE as a valid T syllable,
which is incorrect based on the Unicode specification (TBASE is one
below the start of the range, range beginning at U+11A8).
This would cause the TBASE to be silently swallowed in the
normalization, leading to an incorrect result.
A couple of regression tests are added to check more patterns with
Hangul recomposition and decomposition, on top of a test to check the
problem with TBASE. Diego has submitted the code fix, and I have
written the tests.
Author: Diego Frias <mail@dzfrias.dev> Co-authored-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/B92ED640-7D4A-4505-B09F-3548F58CBB16@dzfrias.dev
Backpatch-through: 14
doc: Mention online checksum enabling in pg_checksums docs
The documentation for bin/pg_checksums refered to online processing only
in passing, this extends the documentation to list online checksums as as
alternative as well as providing a link to the new Data Checksums section.
Author: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Bruce Momjian <bruce@momjian.us> Reported-by: Bruce Momjian <bruce@momjian.us>
Discussion: https://postgr.es/m/aiHKJWa1k28fFTqf@momjian.us
Andres Freund [Thu, 4 Jun 2026 18:55:57 +0000 (14:55 -0400)]
ci: Remove support for cirrus-ci based CI
As mentioned in the earlier commit, cirrus-ci has shut down. Therefore remove
all files related to running CI via cirrus. Also update comments / code that
were referencing cirrus-ci.
Andres Freund [Thu, 4 Jun 2026 18:55:57 +0000 (14:55 -0400)]
ci: Add GitHub Actions based CI
Cirrus CI, which the project used for CI until now, has shut down on June 1,
2026. Replace it with GitHub Actions. GitHub Actions was selected because it
has unlimited runner time for public repositories.
The GitHub Actions based CI currently covers:
- SanityCheck
- Linux - Autoconf
- Linux - Meson, (32-bit and 64-bit)
- macOS - Meson
- Windows (Visual Studio + Meson and MinGW + Meson)
- CompilerWarnings
BSD coverage is left for later, as it requires more work.
Note that, for performance reasons, use of address sanitizer was moved to the
Linux - Meson (64-bit) task.
While Actions workflows in new forks are disabled by default, existing forks
that pull new changes into the repository will automatically start running
CI. That may not be desired. There however is no way native to Actions to
prevent this.
To avoid that, each repository that wants real CI to run needs to explicitly
opt into doing so, by creating the 'PG_CI_ENABLED' repository variable with
the value 1.
To make that less confusing, emit a summary whenever we skip running CI, with
a message explaining how to enable CI.
The remaining cirrus-ci support will be removed in a subsequent commit, to
make review easier.
Back-branches will be updated later, after being sure that workflow runs
correctly on master.
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Author: Andres Freund <andres@anarazel.de>
Author: Jelte Fennema-Nio <postgres@jeltef.nl> Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com>
Discussion: https://postgr.es/m/3ydjipcr7kbss57nvi67noplncqhesl5eyb6wgol4ccjxynspv%40yatlykpribmm
Tom Lane [Thu, 4 Jun 2026 16:24:51 +0000 (12:24 -0400)]
Improve reporting of invalid weight symbols in setweight() et al.
This commit addresses two related issues:
tsvector_filter() assumed it could print an incorrect weight value
with %c. This could result in an invalidly-encoded error message
if the database encoding is multibyte and the char value has its
high bit set. Weight values that are ASCII control characters
could render illegibly too. Fix by printing such values in octal
(\ooo), similarly to how charout() would render them.
tsvector_setweight() and tsvector_setweight_by_filter() reported
the same unrecognized-weight error condition with elog(), as though
it were an internal error. That'd not translate, would produce an
unwanted XX000 SQLSTATE code, and also reported the bad value as a
decimal integer which seems unhelpful. Fix by refactoring so that
all three functions share one copy of the code that interprets a
weight argument.
The invalid-encoding aspect seems to me (tgl) to justify
back-patching.
Author: Ewan Young <kdbase.hack@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CAON2xHNaeLAUzRCXL5AmXLcXaSE_gWAVjWQRmLzc_oZ=1_Vf4Q@mail.gmail.com
Backpatch-through: 14
Tom Lane [Thu, 4 Jun 2026 15:37:43 +0000 (11:37 -0400)]
Fix another case of indirectly casting away const.
Like 8f1791c61, this fixes a case of implicitly casting away
const by not treating the result of strrchr() on a const pointer
as const. This was missed at the time because the machines
reporting those warnings weren't building with --with-llvm.
While here, clean up another infelicity: in the probably-
impossible case that the input string contains only one dot,
this function would call pnstrdup() with a length of -1
and thereby emit a module name equal to the function name.
It seems to me we should emit modname = NULL instead.
Also remove a useless Assert and two redundant assignments.
Back-patch, as 8f1791c61 was, so that users of back branches
don't see this warning when building with late-model gcc.
Reported-by: hubert depesz lubaczewski <depesz@depesz.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/aiGNJ89PBqvq2Yyz@depesz.com
Backpatch-through: 14
Tom Lane [Thu, 4 Jun 2026 14:37:25 +0000 (10:37 -0400)]
Ensure USE_AVX... symbols are not defined if not building for x86_64.
Various code assumed this was true already, and usually it is.
However, it emerges that in a "universal" (multi-architecture)
macOS build, configure will define USE_AVX2_WITH_RUNTIME_CHECK
if the build host is x86_64, and then the arm64 half of the
build fails.
Ideally we'd get pg_config.h to define this symbol conditionally
depending on defined(__x86_64__), but I don't see any way to
persuade Autoconf to do that. Instead, clean up the mess by
#undef'ing it again in c.h for not-x86_64 builds.
For consistency I made c.h also #undef the USE_AVX512... symbols.
Those are not actively broken, but it seems only happenstance
that configure's tests for them fail in a universal build.
Down the road we may have occasion to add more #undef's here.
This problem is new in v19, so no need for back-patch.
Reported-by: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> Reported-by: Tobias Bussmann <t.bussmann@gmx.net>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/15574903-87C9-478A-B2D7-CC8F4C275DBB@gmx.net
Require UPDATE permission on FOR PORTION OF column
It seems like the SQL standard does require this after all, and it
makes sense because these columns get changed. (This is not to be
confused with *not* requiring INSERT permission to add the temporal
leftovers.)
Adding the column to RTEPermissionInfo->updatedCols also fixes a
couple outstanding bugs from other (non-permission) features using
that bitmapset to detect changes: GENERATED columns and UPDATE OF
triggers. This patch includes test cases to exercise those scenarios,
including on partitioned tables.
Author: Paul A. Jungwirth <pj@illuminatedcomputing.com> Reviewed-by: jian he <jian.universality@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/CAHg%2BQDcd%3Dt69gLf9yQexO07EJ2mx0Z70NFHo6h94X1EDA%3DhM0g%40mail.gmail.com
Fix cross-leftover pollution in FOR PORTION OF insert triggers
When we insert temporal leftovers after an UPDATE FOR PORTION OF, we
must make a new copy of the tuple before each insert. Otherwise, if
an insert trigger assigns to attributes of NEW, the second leftover
sees those changes.
Author: Sergei Patiakin <sergei.patiakin@enterprisedb.com> Reviewed-by: Paul A Jungwirth <pj@illuminatedcomputing.com>
Discussion: https://www.postgresql.org/message-id/flat/CANE55rCqcse_pwXBMWhbj3_7XROb8Dks6%3DOLFmKy3bO3zDsCsg%40mail.gmail.com
Michael Paquier [Thu, 4 Jun 2026 06:12:11 +0000 (15:12 +0900)]
libpq: Fix "servicefile" after fallback to system service file
When "servicefile" is specified in a connection string but the requested
service is not found in this file, libpq falls back to a default file,
pg_service.conf in PGSYSCONFDIR. The "servicefile" option was missing
an update in this case, causing an incorrect value to be reported,
impacting SERVICEFILE in psql, for example.
An extra update of the option is added in this commit, based on the
actual file where the service name has been found. A test is added to
cover this problem.
pg_dump: scope indAttNames per index in getIndexes()
getIndexes() declared indAttNames and nindAttNames in the outer
per-table loop, so the names collected for an index on expressions
were carried over to the next plain index in the same table.
This is an internal inconsistency rather than a user-facing bug.
dumpRelationStats_dumper() only walks indexes that have pg_statistic
rows, and ANALYZE only creates those for indexes with expressions,
so the second index in the affected pair is not visited and the stale
array is never consulted.
Fix by moving the two variables into the inner per-index loop so each
iteration starts with a clean slate.
Author: Maksim Melnikov <m.melnikov@postgrespro.ru> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>
Discussion: https://postgr.es/m/be5fc489-587e-421f-bbb8-adb43cfd50f4@postgrespro.ru
Backpatch-through: 17
Fujii Masao [Wed, 3 Jun 2026 09:44:56 +0000 (18:44 +0900)]
Fix race in ReplicationSlotRelease() for ephemeral slots
When releasing an ephemeral replication slot, ReplicationSlotRelease()
drops the slot via ReplicationSlotDropAcquired().
However, after dropping the slot, ReplicationSlotRelease() continued
to use its local "slot" pointer, which still referenced the dropped
slot's former shared-memory entry. It could then update fields such as
effective_xmin in that entry.
Once an ephemeral slot has been dropped (via ReplicationSlotDropAcquired()),
its slot array entry can be reused immediately by another backend
creating a new slot. As a result, those updates could corrupt
the state of an unrelated replication slot.
Fix by skipping those shared-memory updates for phemeral slots and
performing them only for non-ephemeral slots, whose shared-memory
entries remain valid after release.
Dean Rasheed [Wed, 3 Jun 2026 08:20:21 +0000 (09:20 +0100)]
Improve overflow/underflow handling in regr_intercept().
As with corr() and regr_r2(), improve regr_intercept()'s final
function to cope with overflow/underflow in the final calculation.
Here, instead of using sqrt(), we use frexp() and ldexp() to recover,
if an overflow or underflow is detected, so that the multiplication
and division steps operate on normalised mantissas, and cannot
overflow or underflow.
As with 6498287696d, and the previous commit improving regr_r2(), this
is arguably a bug fix, but given the lack of prior complaints, refrain
from back-patching.
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
Author: Dean Rasheed <dean.a.rasheed@gmail.com> Reviewed-by: Chengpeng Yan <chengpeng_yan@outlook.com>
Discussion: https://postgr.es/m/33E01656-BB3B-46E9-A41F-24A01A7C35F4@outlook.com
Dean Rasheed [Wed, 3 Jun 2026 08:01:13 +0000 (09:01 +0100)]
Improve overflow/underflow handling in regr_r2().
Commit 6498287696d improved corr()'s final function to cope with
overflow/underflow in the final calculation, and clamped its result to
[-1, 1] in case of roundoff error. Improve regr_r2() in a similar way,
clamping its result to [0, 1].
Arguably this is a bug fix, but given the lack of prior complaints,
refrain from back-patching, as we did with 6498287696d.
Reported-by: Chengpeng Yan <chengpeng_yan@outlook.com>
Author: Chengpeng Yan <chengpeng_yan@outlook.com> Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/33E01656-BB3B-46E9-A41F-24A01A7C35F4@outlook.com
Commit 6429e5b77 changed vacuumdb to process partitioned tables when
--analyze-only or --analyze-in-stages is specified, matching the
documented behavior of analyzing regular tables, partitioned tables,
and materialized views.
Later, commit c4067383cb2 accidentally changed this behavior so that
partitioned tables were processed for --analyze-only, but skipped for
--analyze-in-stages.
As a result, vacuumdb --analyze-in-stages no longer matched its
documentation. Partitioned tables were skipped, leaving parent-table
statistics outdated even though users running vacuumdb
--analyze-in-stages after pg_upgrade, restore, or bulk loading would
expect statistics to be rebuilt for the database.
Fix this issue by making --analyze-in-stages process partitioned
tables again.
Author: Chao Li <lic@highgo.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Discussion: https://postgr.es/m/EDFF0AFB-050F-4FBF-8D4F-B44DC454D957@gmail.com
Michael Paquier [Wed, 3 Jun 2026 03:47:22 +0000 (12:47 +0900)]
Fix copy-paste error in hash_record_extended()
The code failed to initialize the second isnull argument passed to
FunctionCallInvoke(). This is harmless for existing in-core extended
hash support functions, since FunctionCallInvoke() does not use the
value (note that all the in-core extended hash functions are strict),
examining only the argument values. However, extension-provided
extended hash functions could be affected if they inspect
PG_ARGISNULL(1).
Richard Guo [Wed, 3 Jun 2026 01:12:40 +0000 (10:12 +0900)]
Fix eager aggregation for semi/antijoin inner rels
Eager aggregation pushes a partial aggregate down to a base or join
relation, to be finalized after that relation is joined with the rest
of the query. eager_aggregation_possible_for_relation() already
refuses to do this for a relation on the nullable side of an outer
join, but it failed to also refuse it for a relation on the inner side
of a semijoin or antijoin.
Such a join does not emit its inner rows, so a partial aggregate
computed on the inner side does not survive the join and cannot be
combined by the final aggregation. This can happen only for an
aggregate that references no table column, such as count(*): it is
considered computable on any relation, including the inner one,
whereas an aggregate that references a column is anchored to the outer
side and never reaches the inner relation.
The existing outer-join check did not catch this because it consults
nulling_relids, which only tracks joins that null-extend their inner
side. Semijoins and antijoins formed from EXISTS, IN, NOT EXISTS, or
NOT IN sublinks do not null-extend and carry no ojrelid, so they are
invisible to that check.
Fix by additionally rejecting any relation that includes inner-side
relations of a semijoin or antijoin but not the join's outer side.
Pushing a partial aggregate to the outer side of such a join, grouped
by the join key, remains valid and is still allowed.
Reported-by: Radim Marek <radim@boringsql.com>
Author: Richard Guo <guofenglinux@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com>
Discussion: https://postgr.es/m/CAJgoLk+d_P5sKrx-SZt01Acm_j0QnWn6aKJzFJ=waRu_3C8AoQ@mail.gmail.com
Richard Guo [Wed, 3 Jun 2026 00:36:52 +0000 (09:36 +0900)]
Fix wrong unsafe-flag test in check_output_expressions()
The check for window functions (point 4) guarded on the wrong bit: it
tested UNSAFE_NOTIN_DISTINCTON_CLAUSE while setting
UNSAFE_NOTIN_PARTITIONBY_CLAUSE. Each check in this loop guards on
the same bit it is about to set, as an idempotency optimization, since
unsafeFlags[] is accumulated across the arms of a set operation and
there is no point recomputing a column's status once its bit is
present.
This is not a live bug. When UNSAFE_NOTIN_PARTITIONBY_CLAUSE is
already set but UNSAFE_NOTIN_DISTINCTON_CLAUSE is not, the guard fails
to skip targetIsInAllPartitionLists() and recomputes it, but setting
the same bit again changes nothing. When
UNSAFE_NOTIN_DISTINCTON_CLAUSE is already set, point 4 is skipped and
UNSAFE_NOTIN_PARTITIONBY_CLAUSE is left unset; but such a column is
already unsafe for pushdown via UNSAFE_NOTIN_DISTINCTON_CLAUSE, so the
outcome is unchanged.
To fix, test UNSAFE_NOTIN_PARTITIONBY_CLAUSE, matching the bit being
set and the pattern of the surrounding checks.
Back-patch to v15, where the buggy check was introduced.
Author: Richard Guo <guofenglinux@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Reviewed-by: David Rowley <dgrowleyml@gmail.com>
Discussion: https://postgr.es/m/CAMbWs49Q_xnF_P2QSUyDzJ34MnrO7dh-cUAaK2HJPgSgh88NcA@mail.gmail.com
Backpatch-through: 15
Michael Paquier [Tue, 2 Jun 2026 23:58:26 +0000 (08:58 +0900)]
psql: Fix issues with deferred errors in pipelines
When an error is raised while processing a Sync message in a pipeline,
like a deferred constraint violation, the error was not associated with
the piped command and was not counted in available_results. This caused
assertion failures in discardAbortedPipelineResults(), keeping an
incorrect state at pipeline exit, because the code assumed that the
number of available and requested results would always be positive,
expecting all the counters to be 0 at the end of a pipeline.
This commit switches discardAbortedPipelineResults() and
ExecQueryAndProcessResults() to take a softer approach when consuming
and draining the results after an error. If there are still piped syncs
in the pipeline when it ends, we now attempt to consume them before
leaving the pipeline mode.
Alexander has been able to reach two assertion failures through his
testing. While investigating more this issue, I have bumped into two
more. Most of these cases are covered by the regression tests added in
this commit, plus some cases with mixes of pipelines, deferred errors
and results fetched. Some of the tests discussed (like the backend
termination one) could not be included in this commit but have been
tested manually. Another test scenario discussed involved the injection
of an error state in the backend, that was able to trick libpq
internally and put its queue out of sync. This scenario is not going to
happen in practice, but if we were to do something about it we would
need to make libpq understand that it needs to fail in some cases but
not block.
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Author: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/19494-97a86d84fee71c47@postgresql.org
Backpatch-through: 18
Michael Paquier [Tue, 2 Jun 2026 23:16:42 +0000 (08:16 +0900)]
xml2: Fix more memory leaks with libxml2 and XPath evaluations
Several objects were allocated by libxml2 and never released in some
error or even success paths, leading to some memory leaks that would
stack across SQL calls:
- In pgxml_xpath(), the result of xmlXPathCompiledEval() could leak.
This now uses a TRY/CATCH block to ensure a correct cleanup of a
workspace on failure.
- In xpath_table() missed some objects not freed on failure. Some
xmlFree() calls were missing for the results copied after a success.
- In pgxmlNodeSetToText(), xmlXPathCastNodeToString() allocates a result
that the caller is responsible for freeing. It was not freed.
Most of the work of this commit stands on top of 732061150b0, that has
refactored xml2 to make the handling of such leaks easier. The leaks
fixed here are more ancient than the commit mentioned above, and we have
never bothered doing something about them in older stable branches.
Author: Andrey Chernyy <andrey.cherny@tantorlabs.com> Co-authored-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/20260601010124.5edf9a20@andrnote
Andrew Dunstan [Wed, 20 May 2026 00:49:15 +0000 (08:49 +0800)]
Avoid leaking system path from pg_available_extensions
The documentation says that when extension_control_path is set to an
empty string, the default '$system' path is still assumed. However,
get_extension_control_directories() added the system extension directory
with a NULL macro in that case. As a result, pg_available_extensions
could expose the expanded system directory path instead of reporting
'$system' as the location.
Record the implicitly-added system directory with the '$system' macro, so
pg_available_extensions reports the documented symbolic location and does
not leak the actual system path.
Update the extension_control_path TAP test to check the reported location
directly.
Author: Chao Li <lic@highgo.com> Reviewed-by: Lu Feng <fnlo1995@gmail.com> Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com> Reviewed-by: Jim Jones <jim.jones@uni-muenster.de>
Discussion: https://postgr.es/m/357C774A-ECE9-4455-B641-315205D4D9A1@gmail.com
Andrew Dunstan [Mon, 20 Apr 2026 05:46:36 +0000 (11:16 +0530)]
Apply encoding conversion in COPY TO FORMAT JSON
CopyToJsonOneRow() sent the output of composite_to_json() directly
via CopySendData() without encoding conversion. The text and CSV
paths convert per-attribute via pg_server_to_any() when
need_transcoding is true, but the JSON path skipped this entirely.
This meant COPY ... TO ... WITH (FORMAT json, ENCODING 'LATIN1') on
a UTF-8 server silently produced UTF-8 output, and COPY TO STDOUT
with a non-UTF-8 client_encoding would send unconverted bytes to
the client.
Apply pg_server_to_any() to the whole JSON buffer after
composite_to_json() returns, converting to the requested file
encoding when it differs from the server encoding. Tests cover
both the explicit ENCODING option and the implicit case where
file_encoding is inherited from client_encoding.
Introduced by 7dadd38cda9 (json format for COPY TO).
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Reviewed-by: Andrew Dunstan <andrew@dunslane.net>
Discussion: https://postgr.es/m/CAJTYsWX-jsLzxGRAb-dWnEpGYRPbDYHwce8LctVE92LiDfM2Jw@mail.gmail.com
Álvaro Herrera [Fri, 29 May 2026 22:23:25 +0000 (00:23 +0200)]
Allow old WAL recycling during REPACK CONCURRENTLY
During REPACK CONCURRENTLY, logical decoding keeps replication
slot.restart_lsn pinned behind the oldest running transaction, which is
often the long-lived REPACK transaction itself. As a result, old WAL
segments are retained longer than necessary.
This commit advances the replication slot each time WAL insertion
crosses a segment boundary, so obsolete WAL files can be recycled while
REPACK is still running.
Jacob Champion [Fri, 29 May 2026 21:40:20 +0000 (14:40 -0700)]
doc: Correct the timeline for OAuth's shutdown_cb
During original feature development, the OAuth validator shutdown
callback was invoked via before_shmem_exit(). That was changed to use a
reset callback before commit, but I forgot to update the documentation
for validator developers.
Correct this and backport to 18, where OAuth was introduced. The
callback is invoked whenever the server is "finished" with token
validation. (We make no stronger guarantees here, in the hopes that this
API might successfully navigate future multifactor authentication
support and/or changes to the server threading model.)
OpenSSL 4.0.0 changed some parameters and returnvalues to const, so
we need to update our declarations and subsequently cast away const-
ness from a few callsites to make libpq build without warnings. This
is tested with OpenSSL 1.1.1 through 4.0.0 as well as with LibreSSL.
No functional change is introduced, this commit only allows postgres
to be compiled against OpenSSL 4.0.0 without warnings.
There is also an errormessage change in OpenSSL 4.0.0 which needed
to be covered by our testharness.
This will be backpatched to all supported branches since they are
all equally likely to be built against OpenSSL 4.0.0 as it becomes
available in distributions. Backpatching will be done once it has
been in master for a few days without issues.
Author: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/066B07BB-85FA-487C-BE8C-40F791CFC3C4@yesql.se
Backpatch-through: 14
The launcher and worker for enabling/disabling checksums were named
"datachecksum worker|launcher" but using the plural form makes more
sense given the underlying GUC name data_checksums.
Author: Daniel Gustafsson <daniel@yesql.se> Reported-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://postgr.es/m/20260528.121622.1662808269492494574.horikyota.ntt@gmail.com
The datachecksums launcher was using int for storing a PID, but
the correct type is pid_t (which is defined to be a signed int).
Author: Tomas Vondra <tomas@vondra.me> Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://postgr.es/m/f1281cf3-89a3-4936-9bc5-2a5a6291229f@vondra.me
Spelling fixes and rewording outdated information.
Author: Tomas Vondra <tomas@vondra.me> Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://postgr.es/m/f1281cf3-89a3-4936-9bc5-2a5a6291229f@vondra.me
When a standby is promoted to primary during checksum enabling when the
state is inprogress-on, the standby shall revert the state to off since
checksums weren't fully enabled at the time of the crash. Consider the
following scenario:
1) primary/standby cluster has checksums off
2) primary starts enabling checksums
3) primary moves to inprogress-on
4) standby receives that and moves to inprogress-on too
5) primary crashes
6) standby gets promoted, and does the StartupXLOG thing
7) standby moves from inprogress-on back to off
Any processes in the standby need to be informed at step 6 to change
state with a procsignalbarrier, else they will stay in inprogress-on
while new backends will see the state as off. StartupXLOG failed to
emit a procsignalbarrier which caused inconsistent state in the node
promoted to primary.
Fixed by emitting a procsignalbarrier during promotion, and adding a
new test for this scenario.
Author: Daniel Gustafsson <daniel@yesql.se> Reported-by: Tomas Vondra <tomas@vondra.me>
Discussion: https://postgr.es/m/f1281cf3-89a3-4936-9bc5-2a5a6291229f@vondra.me
Álvaro Herrera [Fri, 29 May 2026 19:10:01 +0000 (21:10 +0200)]
Advance restart_lsn more eagerly in LogicalConfirmReceivedLocation
The existing logic computed an updated replicationSlotMinLSN from all
slots' restart_lsn only when catalog_xmin also advanced. This is not a
problem in normal (non-repack) cases, because catalog_xmin changes
pretty frequently, so the recomputation is triggered frequently enough.
However, REPACK does not currently change its catalog snapshot, so that
doesn't work very well if no other replication slot is being used.
(After this commit, we still don't recycle WAL properly for REPACK,
because its background worker is not advancing its restart_lsn either;
that will be fixed in a separate commit. However, this preexisting
problem in older code is logically separate from that one.)
Author: Zhijie Hou <houzj.fnst@fujitsu.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
Discussion: https://postgr.es/m/TY4PR01MB17718B44164522D0798F8E898940A2@TY4PR01MB17718.jpnprd01.prod.outlook.com
Jacob Champion [Fri, 29 May 2026 18:34:12 +0000 (11:34 -0700)]
libpq: Send users to the wiki during grease failures
The existing documentation link for grease errors is fine, but something
a little more user-friendly and updatable would be ideal, since the
campaign won't last very long. The page
https://wiki.postgresql.org/wiki/Grease
has been added for this purpose. (It's admin-protected, to avoid making
it a spam target).
Robert Haas [Fri, 29 May 2026 17:51:09 +0000 (13:51 -0400)]
pg_plan_advice: DO_NOT_SCAN is a simple tag, not a generic one.
Generic tags allow sublists, e.g. MERGE_JOIN((x y)), but simple
tags do not, e.g. SEQ_SCAN(x) is valid but SEQ_SCAN((x)) is not.
DO_NOT_SCAN was intended to be simple tag, but was accidentally
implemented as a generic one. This could result in assertion
failures. Repair.
Álvaro Herrera [Fri, 29 May 2026 09:54:00 +0000 (11:54 +0200)]
Cover additional errors and corner conditions in repack.c
The coverage report shows that some error cases were not being tested;
add test cases for them.
While at it, move some recently added ones to the test_decoding suite:
the preventative check added in 43649b6a53e9 now causes servers with
wal_level=minimal to error out earlier than before.
Álvaro Herrera [Thu, 28 May 2026 18:29:20 +0000 (20:29 +0200)]
Improve REPACK (CONCURRENTLY) error messages some more
We had discussed changing the wording of messages from "cannot repack
table X" to "cannot execute REPACK on table X", so that translators
don't have to figure out how to translate REPACK as a verb in their
language. We already do that for VACUUM and others and it's not very
nice. Also remove extra double-quotes in a message of that form which I
mistakenly added in commit 43649b6a53e9.
While at it, add specific error messages for the cases of a table with a
deferrable primary key, and of REPLICA IDENTITY FULL; otherwise the user
gets a message that the table doesn't have an identity index and it's
not clear why that is.
projects / thirdparty / postgresql.git / log
