Re: BUG #18127: Assertion HaveRegisteredOrActiveSnapshot failed on REINDEX CONCURRENTLY when blocksize=1 - Mailing list pgsql-bugs

From Alexander Lakhin
Subject Re: BUG #18127: Assertion HaveRegisteredOrActiveSnapshot failed on REINDEX CONCURRENTLY when blocksize=1
Date
Msg-id 9541c507-a325-7768-38b0-90f6532c01e3@gmail.com
Whole thread Raw
In response to BUG #18127: Assertion HaveRegisteredOrActiveSnapshot failed on REINDEX CONCURRENTLY when blocksize=1  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #18127: Assertion HaveRegisteredOrActiveSnapshot failed on REINDEX CONCURRENTLY when blocksize=1
Re: BUG #18127: Assertion HaveRegisteredOrActiveSnapshot failed on REINDEX CONCURRENTLY when blocksize=1
List pgsql-bugs
21.09.2023 14:00, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference:      18127
>
> A server compiled --with-blocksize=1 produces an assertion failure on
> `make check`. More specifically, the failure triggered on a query like:
> CREATE TABLE concur_reindex_tab (c1 int PRIMARY KEY);
> CREATE TABLE concur_reindex_tab2 (c1 int REFERENCES concur_reindex_tab);
> REINDEX INDEX CONCURRENTLY concur_reindex_tab_pkey;

With the attached patch, which, as I believe, represents a real
possibility during code execution, I could perform check-world without
changing the block size. It gave me other code paths to reach that
assertion failure:
1) ALTER TABLE range_parted2 DETACH PARTITION part_rp CONCURRENTLY
#5  0x0000555e8b668a01 in ExceptionalCondition (conditionName=conditionName@entry=0x555e8b6ca710 
"HaveRegisteredOrActiveSnapshot()", fileName=fileName@entry=0x555e8b6dbe02 "toast_helper.c", 
lineNumber=lineNumber@entry=281)
     at assert.c:66
...
#9  0x0000555e8b15c637 in simple_heap_update (...) at heapam.c:4044
#10 0x0000555e8b20510c in CatalogTupleUpdate (...) at indexing.c:322
#11 0x0000555e8b2e1bf6 in DetachPartitionFinalize (...) at tablecmds.c:19428
...

2) src/test/subscription/t/021_twophase.pl
Core was generated by `postgres: subscriber: logical replication apply worker for subscription 16389 '.
...
#5  0x000055dae548da01 in ExceptionalCondition (conditionName=conditionName@entry=0x55dae54ef710 
"HaveRegisteredOrActiveSnapshot()", fileName=fileName@entry=0x55dae5500e02 "toast_helper.c", 
lineNumber=lineNumber@entry=281)
     at assert.c:66
...
#9  0x000055dae4f81637 in simple_heap_update (...) at heapam.c:4044
#10 0x000055dae502a10c in CatalogTupleUpdate (...) at indexing.c:322
#11 0x000055dae52c70ca in UpdateTwoPhaseState (...) at tablesync.c:1752
#12 0x000055dae52ce2e1 in run_apply_worker () at worker.c:4539

3) src/test/subscription/t/029_on_error.pl
Core was generated by `postgres: subscriber: logical replication tablesync worker for subscription 163'.
...
#5  0x0000556c27961a01 in ExceptionalCondition (conditionName=conditionName@entry=0x556c279c3710 
"HaveRegisteredOrActiveSnapshot()", fileName=fileName@entry=0x556c279d4e02 "toast_helper.c", 
lineNumber=lineNumber@entry=281)
     at assert.c:66
...
#9  0x0000556c27455637 in simple_heap_update (...) at heapam.c:4044
#10 0x0000556c274fe10c in CatalogTupleUpdate (...) at indexing.c:322
#11 0x0000556c2751fc98 in DisableSubscription (...) at pg_subscription.c:196
#12 0x0000556c277a1d03 in DisableSubscriptionAndExit () at worker.c:4725
#13 0x0000556c2779a935 in start_table_sync (...) at tablesync.c:1623

These are all code paths that were detected during check-world.

Andres, could you please look at this and determine whether the state,
highlighted by the assert, is unexpected?

Best regards,
Alexander
Attachment

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #18130: \copy fails with "could not read block" or "page should be empty but not" errors due to triggers
Next
From: Aleš Zelený
Date:
Subject: Re: Invalid dump file after drop of role that previously created extension containing a table.