Re: BUG #18127: Assertion HaveRegisteredOrActiveSnapshot failed on REINDEX CONCURRENTLY when blocksize=1

Поиск
Список
Период
Сортировка
От Alexander Lakhin
Тема Re: BUG #18127: Assertion HaveRegisteredOrActiveSnapshot failed on REINDEX CONCURRENTLY when blocksize=1
Дата
Msg-id 9541c507-a325-7768-38b0-90f6532c01e3@gmail.com
обсуждение исходный текст
Ответ на BUG #18127: Assertion HaveRegisteredOrActiveSnapshot failed on REINDEX CONCURRENTLY when blocksize=1  (PG Bug reporting form <noreply@postgresql.org>)
Ответы Re: BUG #18127: Assertion HaveRegisteredOrActiveSnapshot failed on REINDEX CONCURRENTLY when blocksize=1  (Michael Paquier <michael@paquier.xyz>)
Re: BUG #18127: Assertion HaveRegisteredOrActiveSnapshot failed on REINDEX CONCURRENTLY when blocksize=1  (Andres Freund <andres@anarazel.de>)
Список 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
Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #18130: \copy fails with "could not read block" or "page should be empty but not" errors due to triggers
Следующее
От: Aleš Zelený
Дата:
Сообщение: Re: Invalid dump file after drop of role that previously created extension containing a table.