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
Re: BUG #18127: Assertion HaveRegisteredOrActiveSnapshot failed on REINDEX CONCURRENTLY when blocksize=1 |
| Список | 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 по дате отправления: