REPACK hits assertion failure on postmaster death exit

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

Responses

Browse pgsql-hackers by date

  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