| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Tristan Partin <tristan(at)partin(dot)io>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Fix publisher-side sequence permission reporting |
| Date: | 2026-06-24 08:50:17 |
| Message-ID: | CAHGQGwH1Ssze3XM6wjoTjSLVOR041c6xP+vsdLP951=w8oG8bA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 24, 2026 at 4:40 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> Assume a case where the primary fails and the system promotes standby
> as a new primary. Then the subscriber starts sync from the new
> primary, there it can lead to an unlogged sequence sync scenario?
When I tested pg_get_sequence_data() with an unlogged sequence on
new primary after promotion, I hit an assertion failure...
---------------------
1. Create an unlogged sequence on the primary:
=# CREATE UNLOGGED SEQUENCE myseq;
CREATE SEQUENCE
2. Confirm that pg_get_sequence_data() returns NULL values on the standby:
=# SELECT * FROM pg_get_sequence_data('myseq');
last_value | is_called | page_lsn
------------+-----------+----------
(null) | (null) | (null)
(1 row)
3. Promote the standby, then call pg_get_sequence_data() on the new primary:
=# SELECT * FROM pg_get_sequence_data('myseq');
This results in the following assertion failure:
TRAP: failed Assert("((const PageHeaderData *) page)->pd_special >=
SizeOfPageHeaderData"), File:
"../../../src/include/storage/bufpage.h", Line: 357, PID: 96253
0 postgres 0x000000010d8d1412
ExceptionalCondition + 178
1 postgres 0x000000010d316970
PageValidateSpecialPointer + 128
2 postgres 0x000000010d3142df read_seq_tuple + 79
3 postgres 0x000000010d31635e
pg_get_sequence_data + 382
4 postgres 0x000000010d3bc42e
ExecMakeTableFunctionResult + 702
5 postgres 0x000000010d3da6cf FunctionNext + 175
6 postgres 0x000000010d3bde92 ExecScanFetch + 626
7 postgres 0x000000010d3bd88f ExecScanExtended + 95
8 postgres 0x000000010d3bd81f ExecScan + 95
9 postgres 0x000000010d3da2c5 ExecFunctionScan + 53
10 postgres 0x000000010d3b8a2b
ExecProcNodeFirst + 75
11 postgres 0x000000010d3affee ExecProcNode + 46
12 postgres 0x000000010d3ab507 ExecutePlan + 199
13 postgres 0x000000010d3ab3e0
standard_ExecutorRun + 368
14 postgres 0x000000010d3ab263 ExecutorRun + 67
15 postgres 0x000000010d6c2710 PortalRunSelect + 256
16 postgres 0x000000010d6c2170 PortalRun + 672
17 postgres 0x000000010d6bd53c
exec_simple_query + 1292
18 postgres 0x000000010d6bc6e5 PostgresMain + 2981
19 postgres 0x000000010d6b5228 BackendMain + 168
20 postgres 0x000000010d5a2269
postmaster_child_launch + 377
21 postgres 0x000000010d5a8775 BackendStartup + 277
22 postgres 0x000000010d5a6d85 ServerLoop + 341
23 postgres 0x000000010d5a5b84 PostmasterMain + 5748
24 postgres 0x000000010d43e533 main + 771
25 dyld 0x00007ff80fc71530 start + 3056
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Regards,
--
Fujii Masao
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2026-06-24 08:52:24 | Re: [PATCH] Fix null pointer dereference in PG19 |
| Previous Message | Jakub Wartak | 2026-06-24 08:48:19 | Re: Problems with get_actual_variable_range's VISITED_PAGES_LIMIT |