Tied hashes, and probably tied arrays, are capable of returning Perl
value pointers that are actually NULL, not the usual pointer to an
undef SV. We were not defending against that everywhere, leading
to possible SIGSEGV. Fix the code to consistently treat a null
pointer returned from hv_iternext or av_fetch like a !SvOK one.
(Note that the large diff in SV_to_JsonbValue is actually quite
trivial, but it required reindenting a chunk of existing code.)
Claude Code found the instance in hstore_plperl, and I found the
others by code auditing. Perhaps the other instances aren't
actually reachable, but I see little reason to assume that.
The known test cases for these errors require perl's Tie modules,
which may not be present, so it doesn't seem worth the trouble
to create regression test cases that would cover them.
Reported-by: Claude Code (via Noah Misch)
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/569769.1786901901@sss.pgh.pa.us
Backpatch-through: 14
Virtual generated columns are stored in tuples as null values, so
heap_getattr() in tuple_to_stringinfo() always returns null for them.
test_decoding printed such a column as null, which is
indistinguishable from a column that genuinely holds null.
This commit skips virtual generated columns in tuple_to_stringinfo(),
the only place that prints a tuple. Stored generated columns continue
to be printed, since their values do live in the heap tuple.
This is a behavior change rather than a bug fix, and it changes
test_decoding's output for tables that have virtual generated columns,
which could affect consumers that parse it. Therefore it is not
back-patched.
Author: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Co-authored-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Reviewed-by: Euler Taveira <euler@eulerto.com>
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>
Discussion: https://postgr.es/m/CAHg+QDfTh3UbB-Ed--o2Bd=SBDJoEiG-qp3C0+ETDibF63y=dw@mail.gmail.com
Commit 51f55b13a4 added a test where DROP DATABASE ... WITH (FORCE)
terminates a session holding a temporary table in the target database.
While exiting, the terminated session drops its temporary table and
commits, and the commit waits for a WAL flush behind the backlog
generated by the checksum workers. On machines with slow storage this
can exceed the five seconds DROP DATABASE waits for terminated backends
to exit, making the test fail with "database "dropmeforce" is being
accessed by other users", as observed on buildfarm member turaco.
To fix, use asynchronous commit in the terminated session, so that its
exit does not wait for a WAL flush, and checkpoint before the drop so
that the exit-time WAL records do not queue up behind the backlog.
Author: Zsolt Parragi <zsolt.parragi@percona.com>
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/361531e2-52b5-499c-a126-815f277bbef2@gmail.com
Backpatch-through: 19
A few catalog queries were missing proper schema qualification in the
test_checksums module test suites, and one suite contained a disable
call right before tearing down the test which can be removed.
Backpatch to v19 where the test suite was added.
Author: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://postgr.es/m/8CF9B235-AEE9-4E68-93DD-DF4F29E2FCE5@yesql.se
Backpatch-through: 19
Enabling data checksums in a running cluster changes the state to "on"
before the checkpoint which flushes the pages the worker rewrote. A
base backup which started before that transition absorbs the barrier
mid-run and starts verifying pages whose on-disk copies legitimately
lack checksums, and whose LSNs predate the backup start, so the LSN
check does not skip them either. The backup fails with bogus
corruption warnings. The same applies to checksums being disabled and
re-enabled while the backup runs: hint bits set while checksums were
off reach disk without a checksum update and without moving the page
LSN, tripping verification once the re-enabling completes.
To fix, verify checksums only while they have been continuously
enabled since the checkpoint the backup started from: track the
location of the last XLOG2_CHECKSUMS record inserted or replayed, and
verify only when the state is "on" and the last change predates the
backup start. The starting checkpoint then guarantees that every page
flushed before it has a checksum written, and any later change
disables verification for the rest of the backup.
A standby loses the tracked location when restarting, while pg_control
already carries the new state, so it could reach consistency below the
record and serve base backups with the location unknown. To prevent
this, replaying XLOG2_CHECKSUMS advances minRecoveryPoint to the
record, like XLOG_PARAMETER_CHANGE does.
The tests hold the enabling between the state change and its final
checkpoint with injection points, straddling it with backups on the
primary and across a standby crash-restart.
Author: Zsolt Parragi <zsolt.parragi@percona.com>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://postgr.es/m/CAN4CZFP=-cVVVPue+e8qqPtDfuLuQn=ZB4Mw_C9-Ncru2wqAsQ@mail.gmail.com
Backpatch-through: 19
Commit f19c0eccae added the data_checksum_version to the pg_controldata
output, but omitted a corresponding change to the pg_control_checkpoint
SQL function, which reports the same checkpoint information. The field
is named to match what pg_control_init already reports for consistency.
The integer version reported is an implementation detail which bleeds
through, but it is quite widely used and a more holistic approach to
improving this is left as an excercise for the next major version. The
mapping between states and versions is added to the documentation to
make it easier for users.
Backpatch to v19 where online checksums were introduced.
Author: Ian Barwick <barwick@gmail.com>
Co-authored-by: Daniel Gustafsson <daniel@yesql.se>
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: Chao Li <li.evan.chao@gmail.com>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Discussion: https://postgr.es/m/CAB8KJ=hb765sE8bKC-6sh=Yp3sCjN8xs474yuBrkwyoTM2pgZA@mail.gmail.com
Backpatch-through: 19
The controlfile records the current state of data checksums, which
also used to be the initial state from initdb when checksums could
not be altered after initialization. pg_control_init is documented
to return information about cluster initialization state, which it
no longer will if data checksums have been changed either using the
offline tool or with online processing.
Fix by adding a new field in the control file which tracks the init
value of data checksums, and is left read only after initialization.
While this is a regression dating back to when changing checksum
state was made possible offline with pg_checksums, it is a control
file change so it cannot be backpatched.
Backpatch to v19 where online checksums were introduced.
Author: Daniel Gustafsson <daniel@yesql.se>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Discussion: https://postgr.es/m/B87ABFBE-A304-4839-8706-C80D73E6BF5C@yesql.se
Backpatch-through: 19
Commit 072ee847ad taught logical decoding to discard the changes of a
transaction that is already known to be aborted when it is picked for
eviction. That path reuses ReorderBufferTruncateTXN(), which marks
every subtransaction that still has in-memory changes as
streamed. Since nothing is streamed in that path, and the top-level
transaction is never marked, a subtransaction ends up flagged as
streamed even though the output plugin has never seen it. Decoding the
subsequent abort record then makes ReorderBufferAbort() invoke the
stream_abort callback for that subtransaction.
For pgoutput this sends a Stream Abort ('A') message to a subscriber
that requested streaming = off, and it does so regardless of the
negotiated protocol version, so even a client speaking a version that
predates transaction streaming receives a message it cannot
parse. test_decoding dereferences a NULL pointer and crashes, since it
allocates its per-transaction state in the begin or stream start
callback, neither of which runs for a transaction discarded as
aborted.
This commit fixes this by marking a subtransaction as streamed only
when it has changes and its top-level transaction is already marked as
streamed. All streaming call sites mark the top-level transaction
before truncating it, so their behavior is unchanged, while the
abort-discard path never marks the top-level transaction and therefore
now leaves its subtransactions unmarked.
Backpatch to v18, where commit 072ee847ad was introduced.
Bug: #19616
Reported-by: Tyler Smart <tyler@smarts.io>
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>
Discussion: https://postgr.es/m/19616-f6153af509910853@postgresql.org
Backpatch-through: 18
A comma following a file ref in a perl print statement makes the
statement just print the file's GLOB rather than redirecting the
following arguments to the file. This meant the test was not testing any
contents and the logs were instead bulked up with what the test was
supposed to be testing.
Also, run_log() returns 1 for success, not 0, so the tests for the
return values were wrong. (We were getting 0 because of the comma error
above.)
Backpatch-thru: 17
WaitLSNWakeup() removes a waiter from the heap before setting its latch.
If the position that caused the wakeup moves backwards before the waiter
rechecks it, as can happen when WAL streaming restarts, the waiter may
sleep again while no longer registered. Subsequent WAL progress then
cannot wake it.
When an unmet waiter finds that it is no longer in the heap, add it back
and restart the loop. Rereading the position after registration also
prevents missing an advance between the previous read and the re-add.
Process interrupts before re-registering rather than after, so that a
wakeup which goes stale again cannot postpone cancellation, however often
it repeats. As a side effect, a pending cancel now wins over an expired
timeout, which previously reported a timeout instead.
Add deterministic TAP coverage that simulates a stale standby_write
wakeup without advancing the actual write or replay positions.
Author: Xuneng Zhou <xunengzhou@gmail.com>
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>
Discussion: https://postgr.es/m/CABPTF7UtW_cAa%3DQh4RDfKiUqu3pJJE22ai9tbWJVERbeRyssLw%40mail.gmail.com
Backpatch-through: 19
WaitLSNWakeup() removes each selected waiter from its heap and clears
its inHeap flag before setting its latch. When such a waiter later
calls deleteLSNWaiter(), it acquires WaitLSNLock exclusively only to
discover that there is nothing left to remove. Waking many waiters can
therefore make them serialize on the lock for no useful work.
Check inHeap before acquiring WaitLSNLock. A lockless false value is
conclusive because only the owning backend can change inHeap from false
to true. A concurrent waker can only clear it. A stale true value
falls through to the existing recheck under the lock.
WaitLSNCleanup() performed the same lockless check before calling
deleteLSNWaiter(). Drop it there, as it is now redundant.
Author: Xuneng Zhou <xunengzhou@gmail.com>
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>
Discussion: https://postgr.es/m/CABPTF7UtW_cAa%3DQh4RDfKiUqu3pJJE22ai9tbWJVERbeRyssLw%40mail.gmail.com
Backpatch-through: 19
WaitLSNCleanup() was called from ProcKill(), but not from
AuxiliaryProcKill(), even though xlogwait.c sizes its shared memory to
include NUM_AUXILIARY_PROCS and thus accepts calls from auxiliary
processes. Such a process exiting while waiting would leave its entry in
the heap.
Register an on_shmem_exit callback lazily before a process enters a
wait-for-lsn heap instead, as suggested by Noah: that keeps the cleanup
local to xlogwait.c and makes it harder to miss a caller that needs it,
rather than having to remember every process-kill path.
Reported-by: Noah Misch <noah@leadboat.com>
Author: Xuneng Zhou <xunengzhou@gmail.com>
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>
Discussion: https://postgr.es/m/20260706012642.f9.noahmisch%40microsoft.com
Discussion: https://postgr.es/m/CABPTF7UtW_cAa%3DQh4RDfKiUqu3pJJE22ai9tbWJVERbeRyssLw%40mail.gmail.com
Backpatch-through: 19
The RI fast path reads pg_constraint.conindid before taking
RowShareLock on the referenced table. REINDEX CONCURRENTLY can
repoint the constraint and mark the old index dead, or drop it,
between those operations. A backend in that window does not yet
hold a relation lock, so it is not covered by REINDEX CONCURRENTLY's
waits for lockers.
Opening an index that has already been dropped produces "could not open
relation with OID". Opening one that has only been marked dead can
produce wrong answers: the index is no longer maintained or vacuumed,
so a scan can miss a referenced row or follow a stale entry to a reused
heap line pointer.
After locking the referenced table, reload the constraint and use its
current conindid. LockRelationOid() processes invalidation messages
after acquiring the lock, so the reload sees a committed index swap.
If the lock was already held, REINDEX CONCURRENTLY cannot mark the old
index dead or drop it until the transaction releases that lock, so
continuing to use the old conindid is safe.
Do this at both RI fast-path call sites. Add injection-point coverage
for old indexes that have either been dropped or marked dead.
Author: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Discussion: https://postgr.es/m/CADzfLwUJiVuv69uwuF5z4TrMhNkVwQUXW03q+uVNwmYFLtjEhw@mail.gmail.com
Backpatch-through: 19
hstore has been relying on a set of int/int32 to count the total length
of all the keys and values constructed, relying on the maximum values of
the arguments rather than proper bound checks. As proved in the
reported thread, these counters could overflow and wrap, leading to
incorrect allocations.
This commit replaces the int/int32 values with a set of Size values,
with add_size() and mul_size() in charge of checking for overflows when
constructing hstore values before doing any allocation.
The changes that matter in terms of the report are mostly in
hstore_io.c. hstore_compat.c is adjusted for consistency, to keep the
allocation maths uniform across the module.
This is an old bug. A backpatch should perhaps be done but I cannot get
excited about a change like that in stable branches.
Reported-by: Man Zeng <zengman@halodbtech.com>
Author: Tender Wang <tndrwang@gmail.com>
Author: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/CAHewXNmfD6-9MDxgpRfTzjVj0mhBw3JMoNOHeTiPOjZGhNzd=g@mail.gmail.com
ri_FastPathFlushArray() rechecked a concurrently updated PK tuple with a
scan key it built itself, putting found_val, the key of the tuple it had
just locked, into sk_argument, and passing that same slot to
recheck_matched_pk_tuple(). Both operands therefore came from the locked
tuple, and since sk_argument is the operator's right-hand input, the PK
value was read as an FK value. For a foreign key using a cross-type
equality operator, such as a "date" primary key referenced by a "timestamp"
column, that compares days against microseconds, so the recheck always
failed and a batch that had to follow an update chain reported a violation
even though the version it locked still had the key.
Remove the recheck. For a same-type key it compared the tuple against
itself and so never rejected anything, which was harmless only because the
loop a few lines below does the real work: it already compares found_val,
read after the chain has been followed, against every buffered FK value,
with the arguments in the order the operator expects. That makes the
recheck redundant as well as wrong. Detection is not weakened by dropping
it, since the buffered value that led the scan to a tuple can be matched by
no other row visible to our snapshot.
ri_FastPathProbeOne() passes its original scan key, with the FK value still
in sk_argument, and was never affected; nor were single-row statements or
multi-column foreign keys, which go through it.
Add an isolation test covering the cross-type case, a permutation where
the key really does move away, and a same-type permutation that should
behave identically.
Reported-by: Peter Geoghegan <pg@bowt.ie>
Co-authored-by: Peter Geoghegan <pg@bowt.ie>
Discussion: https://postgr.es/m/CAH2-WznQjX3GByh_Ju7unuzMcik_5PJ5D7i_=qhwk=gPEkhfVQ@mail.gmail.com
Backpatch-through: 19
textsearch.sgml neglected to mention that the MAXSTRPOS total-length
limit applies to tsquery as well as tsvector. It also claims that
there is a 32K limit on the total number of nodes in a tsquery, which
is wrong. (I suspect that QueryOperator.left may once have been
int16, which would give rise to such a limit. But it's uint32 now,
so you'd hit the 1GB varlena limit well before overflowing that.)
While at it, re-order the bullet points into an order that makes
more sense, to me anyway.
Reported-by: Claude Code (via Noah Misch)
Author: Tom Lane <tgl@sss.pgh.pa.us>
Reviewed-by: Chao Li <li.evan.chao@gmail.com>
Discussion: https://postgr.es/m/455079.1786897319@sss.pgh.pa.us
Backpatch-through: 14
tsqueryrecv() accepted zero-length lexemes, which tsqueryin() doesn't.
It also accepted phrase distance values larger than MAXENTRYPOS,
which tsqueryin() doesn't. While neither of these omissions are
very harmful in themselves, they do allow accepting tsquery values
that will fail in a subsequent textual dump/reload.
Commit 23d9ad771 performed similar tightening of tsvectorrecv(),
but I left off these changes at the time because they didn't seem
to have security implications.
Reported-by: Claude Code (via Noah Misch)
Author: Tom Lane <tgl@sss.pgh.pa.us>
Reviewed-by: Chao Li <li.evan.chao@gmail.com>
Discussion: https://postgr.es/m/455079.1786897319@sss.pgh.pa.us
Backpatch-through: 14
This flag hasn't been useful since the removal of old-style VACUUM FULL,
so remove it now (this includes removing vestigial code that
unnecessarily set the flag).
Also add test coverage of gistprunepage(). Had that test case been
available before now, the issue fixed by this commit would have been
detected by wal_consistency_checking buildfarm animals.
Author: Peter Geoghegan <pg@bowt.ie>
Reviewed-by: Michael Paquiër <michael@paquier.xyz>
Discussion: https://postgr.es/m/CAH2-WznbTsQCrjmd=eSawfPqcxCjSFUkk6Qzd3z+gpNte5i03Q@mail.gmail.com
Backpatch-through: 14
Make sure the launcher cancels the currently running worker by calling
TerminateBackgroundWorker when it receives SIGINT. In order to handle
cases where SIGINT arrives while tje launcher is waiting for a worker
to start or exit, implement a version of WaitForBackgroundWorkerStartup
and WaitForBackgroundWorkerShutdown which checks the abort_requested
signalling. A new test which kills processing with SIGINT is added.
Backpatch to v19 where online checksums were introduced.
Author: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://postgr.es/m/CAHGQGwEQ1-+iPQnUpTXYiHmzSz9ufFVkOK4kL_uyTdYt7jgg0Q@mail.gmail.com
Backpatch-through: 19
This commit adds a new value to StdRdOptIndexCleanup to distinguish
whether it is explicitly set, similar to ViewOptCheckOption's
VIEW_OPTION_CHECK_OPTION_NOT_SET. This changes only the internal
representation; an unset value still defaults to AUTO, and the
option accepts the same input as before.
This is preparatory work for a follow-up commit that will make use
of the new "unset" state.
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Reviewed-by: Sami Imseih <samimseih@gmail.com>
Tested-by: Greg Burd <greg@burd.me>
Tested-by: solai v <solai.cdac@gmail.com>
Discussion: https://postgr.es/m/aFRxC1W_kZU9OjJ9%40nathan
plperl_func_handler()'s stanza for handling an arrayref result in
a SETOF function could loop forever (or at least till OOM) when
given a tied array, since av_fetch won't necessarily ever return
a null pointer in that case. Be consistent with the other places
where we traverse a perl array: call av_len() once and use len+1
as the loop limit, silently ignoring any null pointers we get back
from that range of subscripts.
But actually, Perl's preferred locution for this seems to be to
use av_count() not av_len()+1. av_count() seems better since
there's less risk of forgetting to add 1. Also, both of those
functions return Size_t (or SSize_t) not int, creating at least
a theoretical overflow hazard. While we're modernizing this,
let's use the correct variable type where we can, and include an
overflow check where we can't.
Reported-by: Claude Code (via Noah Misch)
Author: Tom Lane <tgl@sss.pgh.pa.us>
Reviewed-by: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Discussion: https://postgr.es/m/569769.1786901901@sss.pgh.pa.us
Backpatch-through: 14
This commit reimplements autovacuum_enabled as a ternary, using the
support added in commit 4d6a66f675 and following the example of
vacuum_truncate. This changes only the internal representation: an
unset value still behaves as enabled, and the option accepts the
same input as before.
This is preparatory work for a follow-up commit that will make use
of the new "unset" state.
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Reviewed-by: Greg Burd <greg@burd.me>
Reviewed-by: Sami Imseih <samimseih@gmail.com>
Tested-by: solai v <solai.cdac@gmail.com>
Discussion: https://postgr.es/m/aFRxC1W_kZU9OjJ9%40nathan
extract_autovac_opts() returns a palloc'd copy of just the
AutoVacOpts portion of a relation's reloptions, but upcoming work
needs the other StdRdOptions fields, too. Remove it in favor of
calling extractRelOptions() directly. av_relation now caches the
main table's whole StdRdOptions.
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Reviewed-by: Sami Imseih <samimseih@gmail.com>
Tested-by: Greg Burd <greg@burd.me>
Tested-by: solai v <solai.cdac@gmail.com>
Discussion: https://postgr.es/m/aFRxC1W_kZU9OjJ9%40nathan
This is part of a more global effort to modernize the code tree with
safer allocation functions, which offer more protection in terms of:
- stronger type safety guarantees
- size overflow checks, particulary for arrays.
This set of updates includes allocation changes based on
palloc_object(), palloc_array() and repalloc_array(). This work is
similar to 1b105f9472, expanding more the new APIs in the tree in an
incremental fashion.
Author: Tristan Partin <tristan@partin.io>
Discussion: https://postgr.es/m/DKJB5887LGX9.359DV1UMZ1URK@partin.io
As detected by ASAN, the scanner value used when parsing GUC files can
be indeterminate when the flex error handler sigjumps to the old cleanup
path, before yylex_init() is called.
The flex scanner state is now made volatile in ParseConfigFp(), since
its value is assigned after sigsetjmp() and cna be accessed after
siglongjmp(). yylex_init() cannot use a volatile pointer; a temporary
variable is used before assigning the result of yylex_init() to it.
While on it, yy_create_buffer() is changed to detect the case where it
returns a NULL value. Based on my read of the flex code, this cannot be
reached currently. Future upstream changes or changes in the error
logic of the GUC file parsing could make that reachable, and it is four
extra lines of code.
Oversight in d663f150b5.
Reported-by: Ilia Kashintsev <ilia.kashintsev@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Reviewed-by: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Discussion: https://postgr.es/m/19612-24ccb4fc6da7786f@postgresql.org
Backpatch-through: 18
Simple EXISTS subplans can be converted to hashed ANY subplans as
an alternative implementation. Previously, both the original EXISTS
subplan and the converted ANY subplan used names with the
exists_ prefix, making EXPLAIN output harder to read and
pg_plan_advice targets less clear.
Use the exists_to_any_ prefix for converted ANY subplans so that
their names distinguish them from the original EXISTS alternative.
This only changes the names shown by EXPLAIN and used by plan advice;
it does not affect planner behavior.
Author: Yugo Nagata <nagata@sraoss.co.jp>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Reviewed-by: solai v <solai.cdac@gmail.com>
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Discussion: https://postgr.es/m/20260605165641.3950f99ace0aad8f807abe96@sraoss.co.jp
Backpatch-through: 19
Presently, the documentation for logging_collector says that the
collector "is designed to never lose messages," which reads as a
stronger promise than we actually make. The collector does not
fsync the log file or retry failed writes, so log messages can go
missing after an operating system crash, power loss, or a write
error. Reword that sentence and add a note about what is not
guaranteed.
Author: Daniel Bauman <danielbaniel@gmail.com>
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: Zhenwei Shang <a934172442@gmail.com>
Reviewed-by: Robert Treat <rob@xzilla.net>
Discussion: https://postgr.es/m/CAMtj0_a86DdDKkW-ReVpQpqjndVS6GMrwXVpQY4G3-SGY7saMQ%40mail.gmail.com
Backpatch-through: 14
Commit 13b935cd changed hash_get_num_entries to return int64 instead
of long. This fixes a few more users of hash_get_num_entries which
were missed in the original commit.
PGSS_FILE_HEADER is left unchanged since this only affects as of yet
unreleased versions of PostgreSQL. Backpatch to v19 where the int64
change was performed.
Author: Karina Litskevich <litskevichkarina@gmail.com>
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://postgr.es/m/CACiT8iYTkc33YWaA2D3t51Y5s=GqBO7T1zX7bkpSmet2njcLLw@mail.gmail.com
Backpatch-through: 19
PQfn() has been documented as somewhat obsolete since commit
efc3a25bb0 (2003), and commit bd48114937 recently marked it unsafe
because it may write past the end of result_buf when result_is_int
is 0. Furthermore, searches of publicly available code turned up
no callers, only language bindings that expose the function
without using it, so removing it seems unlikely to cause too much
trouble.
Since the symbol is exported, deleting it outright isn't an option,
so instead this commit teaches PQfn() to fail unconditionally with
an error that suggests alternatives. The documentation for the
fast-path interface is replaced with a stub in the "Obsolete or
Renamed Features" appendix. The server's fast-path support is
retained for the benefit of older clients and the frontend large
object interface.
The frontend large object interface, the only in-tree caller, now
uses PQnfn(), the private version of PQfn() added by commit
bd48114937. I considered converting this code away from the
fast-path protocol entirely, but prepared statements can be
deallocated out from under libpq (e.g., by DISCARD ALL), and
PQexecParams() proved noticeably slower, so that is left as a
future exercise.
Reviewed-by: Christoph Berg <myon@debian.org>
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://postgr.es/m/ahXE28klgxIJXBLq%40nathan
When SendQuery() is not told how many COPY FROM STDIN commands the
query string contains (as for -c, \gexec, and \watch), it scans the
string to count them itself. But it called psql_scan() only once,
which stops at the first semicolon, so any COPY FROM STDIN past the
first sub-command was not counted, causing failure of cases that used
to work. Oversight in commit 3045a25ba.
Author: Zsolt Parragi <zsolt.parragi@percona.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CAN4CZFPqa6c+u4uX5jJ8LANHTQ4dxM3m4_8G9WmX_A4-2wuv2A@mail.gmail.com
Backpatch-through: 14
The option added by commit 28972b6fc was named "restore_stats", because
it was calling pg_restore_relation_stats()/pg_restore_attribute_stats()
in place of fetching a remote rowsample. However, those code paths have
been replaced with calls to
import_relation_statistics()/import_attribute_statistics() (cf. commit
54cd6fc83), so the option is now slightly misnamed.
Switch the option to "import_stats", which more closely reflects both
the functions being called internally, and the user's perception of what
the operation is doing.
Back-patch to v19 where commit 28972b6fc went in.
Suggested-by: Etsuro Fujita <etsuro.fujita@gmail.com>
Author: Corey Huinker <corey.huinker@gmail.com>
Discussion: https://postgr.es/m/CADkLM%3DezuspTk3VD-2EM6XtFP-Dfz7cJKtnbn0cB6gocsAgu1g%40mail.gmail.com
Backpatch-through: 19
injection_points is extended so as a caller can attach a string value to
a point, checked with a value provided at runtime. There are a couple
of use cases where this can be useful, to be able to target points for
specific object names.
PID and string conditions can be combined together, so as a point can be
allowed for a specific process and string value at the same time.
The condition string is capped at 255 characters. As the attach SQL
function now takes an optional condition string, it is no longer STRICT,
and rejects NULL inputs. Empty condition strings are also rejected, as
they don't make sense.
Author: Sami Imseih <samimseih@gmail.com>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/CAA5RZ0tsGHu2h6YLnVu4HiK05q+gTE_9WVUAqihW2LSscAYS-g@mail.gmail.com
This new structure is split depending on the stats kind it deals with:
- PGSTAT_KIND_RELATION, for tables.
- PGSTAT_KIND_INDEX, for indexes.
This change designs a cleaner barrier for the handling of stats data
related to tables and indexes, by being able to track precisely what are
the counters used by one or the other for pending data. Using a common
ground for both eases the tracking of Relations in the relcache, with a
structure based on a union separated by stats kind.
The code originally pointed to some counters that may not be used at
all. For example, indexes have no need for the tracking of
sub-transaction data, still the code implied that these could be touched
for an index. A consequence is that PgStat_TableXactStatus is not
renamed, as it is not used by indexes.
Some asserts are added as an extra layer of protection to prevent the
update of fields that should not be touched. find_tabstat_entry() and
find_tabstat_entry_kind() are removed, replaced by a single
find_relstat_entry_kind() able to work for indexes and the rest.
72a6dad1c9 took care of the shared memory and on-disk part of the
split. This focuses on the pending data part at backend level.
Author: Michael Paquier <michael@paquier.xyz>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Discussion: https://postgr.es/m/f572abe7-a1bb-e13b-48c7-2ca150546822@gmail.com
This commit touches both the libpq and backend-side code of channel
binding where respectively pgtls_get_peer_certificate_hash() and
be_tls_get_certificate_hash() are upgraded to retrieve digests using the
method recommended by OpenSSL 3.0: no more direct EVP_sha256() or
similar, just a EVP_MD_fetch() through EVP to get an algorythm type,
based on a name.
The pre-3.0 code is still required for LibreSSL and as long as we
support OpenSSL 1.1.1.
Similar work has been done in b91f79cd08 and 1f3b9bb109.
Author: Mark Atwood <mark@reviewcommit.com>
Co-authored-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/178596055149.1584250.13974609482797470185@reviewcommit.com
