summaryrefslogtreecommitdiff
path: root/src/interfaces/libpq/fe-exec.c
diff options
context:
space:
mode:
authorDaniel Gustafsson <dgustafsson@postgresql.org>2025-04-30 20:36:23 +0200
committerDaniel Gustafsson <dgustafsson@postgresql.org>2025-04-30 20:36:23 +0200
commit7be51eb4e169672d2029d955cb776e2252e6b7d3 (patch)
tree1c26310bda812e3f7eef47823123fd0429b8c2eb /src/interfaces/libpq/fe-exec.c
parentfa4244a43a3776e7795b08d669f5d96d0ae93410 (diff)
Fix assertion failure in snapshot building
Clear any potential stale next_phase_at value from the snapshot builder which otherwise may trip an assertion check ensuring that there is no next_phase_at value. This can be reproduced by running 80 concurrent sessions like the below where $c is a loop counter (assumes there has been 1..$c databases created) : echo " CREATE TABLE replication_example(id SERIAL PRIMARY KEY, somedata int, text varchar(120)); SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot_$c', 'test_decoding'); SELECT data FROM pg_logical_slot_get_changes('regression_slot_$c', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1'); " | psql -d regress_$c >>psql.log & This was originally committed as 48efb23 and backpatched down to v16, but since then there have been reports of this happening on v14 and v15 as well so this is a backpatch of 48efb23 down to 14. Bug: #17695 Author: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Alexander Lakhin <exclusion@gmail.com> Reported-by: bowenshi <zxwsbg@qq.com> Reported-by: Alexander Pyhalov <a.pyhalov@postgrespro.ru> Reported-by: Teja Mupparti Discussion: https://postgr.es/m/17695-6be9277c9295985f@postgresql.org Backpatch-through: v14
Diffstat (limited to 'src/interfaces/libpq/fe-exec.c')
0 files changed, 0 insertions, 0 deletions