| From: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | REPACK hits assertion failure on postmaster death exit |
| Date: | 2026-10-08 11:38:59 |
| Message-ID: | CALdSSPjx8GK7Uj7p6ujeoaKd_Pw8Y_RsdshZSmrftvAVQMNOfg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I was fuzzing for a different issue in our non-upstream patchset, but
I bumped into something that looks like an REPACK issue in master.
Attached test reproduces assert failure on
5c74e122ef295e251be43a8ce0c561e91fcd000d and latest REL_19_STABLE
Backend running REPACK (CONCURRENTLY) fails to exit cleanly if the
postmaster is killed while the command is in progress.
060 tap test attached reproduces this, postgres logs assertions failure
TRAP: failed Assert("!IsTransactionOrTransactionBlock()"), File:
"pgstat.c", Line: 748, PID: 2166030
postgres: primary: reshke postgres [local] CREATE
INDEX(ExceptionalCondition+0x70)[0x5a5b682abb80]
postgres: primary: reshke postgres [local] CREATE
INDEX(pgstat_report_stat+0x3da)[0x5a5b6815cfaa]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x5ca83b)[0x5a5b6815d83b]
postgres: primary: reshke postgres [local] CREATE
INDEX(shmem_exit+0x59)[0x5a5b681107d9]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x57d93c)[0x5a5b6811093c]
postgres: primary: reshke postgres [local] CREATE
INDEX(proc_exit+0x1f)[0x5a5b681109ff]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x58d361)[0x5a5b68120361]
postgres: primary: reshke postgres [local] CREATE
INDEX(WaitLatch+0x88)[0x5a5b68111378]
postgres: primary: reshke postgres [local] CREATE
INDEX(ConditionVariableTimedSleep+0xd9)[0x5a5b68121a99]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x5595c5)[0x5a5b680ec5c5]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x57d93c)[0x5a5b6811093c]
postgres: primary: reshke postgres [local] CREATE
INDEX(proc_exit+0x1f)[0x5a5b681109ff]
postgres: primary: reshke postgres [local] CREATE
INDEX(errfinish+0x280)[0x5a5b682b0d80]
postgres: primary: reshke postgres [local] CREATE
INDEX(AtEOXact_Parallel+0x30)[0x5a5b67dddc30]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x25822b)[0x5a5b67deb22b]
postgres: primary: reshke postgres [local] CREATE
INDEX(AbortOutOfAnyTransaction+0x55)[0x5a5b67debd85]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x72b53d)[0x5a5b682be53d]
postgres: primary: reshke postgres [local] CREATE
INDEX(shmem_exit+0x59)[0x5a5b681107d9]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x57d93c)[0x5a5b6811093c]
postgres: primary: reshke postgres [local] CREATE
INDEX(proc_exit+0x1f)[0x5a5b681109ff]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x58d361)[0x5a5b68120361]
postgres: primary: reshke postgres [local] CREATE
INDEX(WaitLatch+0x88)[0x5a5b68111378]
postgres: primary: reshke postgres [local] CREATE
INDEX(ConditionVariableTimedSleep+0xd9)[0x5a5b68121a99]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x5595c5)[0x5a5b680ec5c5]
postgres: primary: reshke postgres [local] CREATE
INDEX(WaitReadBuffers+0x1d7)[0x5a5b680fbbf7]
postgres: primary: reshke postgres [local] CREATE
INDEX(read_stream_next_buffer+0x3ec)[0x5a5b680f240c]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x1e62d7)[0x5a5b67d792d7]
postgres: primary: reshke postgres [local] CREATE
INDEX(heap_getnext+0x75)[0x5a5b67d7a715]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x1f4ce5)[0x5a5b67d87ce5]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x225835)[0x5a5b67db8835]
postgres: primary: reshke postgres [local] CREATE
INDEX(btbuild+0x1230)[0x5a5b67dba490]
postgres: primary: reshke postgres [local] CREATE
INDEX(index_build+0xe6)[0x5a5b67e25a86]
postgres: primary: reshke postgres [local] CREATE
INDEX(index_create+0x10a1)[0x5a5b67e27111]
postgres: primary: reshke postgres [local] CREATE
INDEX(DefineIndex+0x993)[0x5a5b67ec8da3]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x5b668f)[0x5a5b6814968f]
postgres: primary: reshke postgres [local] CREATE
INDEX(standard_ProcessUtility+0x1e9)[0x5a5b681484f9]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x5b3bfc)[0x5a5b68146bfc]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x5b3d3d)[0x5a5b68146d3d]
postgres: primary: reshke postgres [local] CREATE
INDEX(PortalRun+0x162)[0x5a5b68147282]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x5afe6d)[0x5a5b68142e6d]
postgres: primary: reshke postgres [local] CREATE
INDEX(PostgresMain+0x1826)[0x5a5b68144b16]
postgres: primary: reshke postgres [local] CREATE
INDEX(BackendMain+0x53)[0x5a5b6813e9c3]
postgres: primary: reshke postgres [local] CREATE
INDEX(postmaster_child_launch+0x111)[0x5a5b6807bcd1]
postgres: primary: reshke postgres [local] CREATE
INDEX(+0x4ec972)[0x5a5b6807f972]
postgres: primary: reshke postgres [local] CREATE
INDEX(PostmasterMain+0xdfd)[0x5a5b6808156d]
postgres: primary: reshke postgres [local] CREATE
INDEX(main+0x1ce)[0x5a5b67d237de]
/lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca)[0x72559ba2a1ca]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b)[0x72559ba2a28b]
postgres: primary: reshke postgres [local] CREATE
INDEX(_start+0x25)[0x5a5b67d23b55]
===
diff also contains some code churn that makes assert failure vanish,
but I don't yet decide if fixing that way is OK. Looks like this just
masks errors. Both test and fix are AI-generated, which I don't feel
bad for, because the issue is real, so use attached just as drafts
demonstrating the issue.
Also I'm in the airport right now, so I don't think I would be able to
reply in the thread by EOW.
--
Best regards,
Kirill Reshke
| Attachment | Content-Type | Size |
|---|---|---|
| fix-repack-postmaster-exit-trap-v1-rel19-0001-test.patch | application/octet-stream | 5.7 KB |
| fix-repack-postmaster-exit-trap-v1-0001-test.patch | application/octet-stream | 5.7 KB |
| fix-repack-postmaster-exit-trap-v1-rel19-0002-fix.patch | application/octet-stream | 3.9 KB |
| fix-repack-postmaster-exit-trap-v1-0002-fix.patch | application/octet-stream | 3.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Manu | 2026-10-08 11:48:02 | Re: [PATCH] Extensible ReadyForQuery wire protocol message and C hook, for connection pools and WAIT FOR LSN |
| Previous Message | John Naylor | 2026-10-08 11:21:53 | Re: Improving scalability of Parallel Bitmap Heap/Index Scan |