Content-Type: multipart/mixed; boundary="------------T21k0FKoF1J09eVjzD47sjI0"
Message-ID: <9541c507-a325-7768-38b0-90f6532c01e3@gmail.com>
Date: Fri, 22 Sep 2023 15:00:01 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: BUG #18127: Assertion HaveRegisteredOrActiveSnapshot failed on
 REINDEX CONCURRENTLY when blocksize=1
Content-Language: en-US
To: pgsql-bugs@lists.postgresql.org, Andres Freund <andres@anarazel.de>
References: <18127-fe54b6a667f29658@postgresql.org>
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <18127-fe54b6a667f29658@postgresql.org>
Archived-At: 
 <https://www.postgresql.org/message-id/9541c507-a325-7768-38b0-90f6532c01e3%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------T21k0FKoF1J09eVjzD47sjI0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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
--------------T21k0FKoF1J09eVjzD47sjI0
Content-Type: text/x-patch; charset=UTF-8; name="hroas-test.patch"
Content-Disposition: attachment; filename="hroas-test.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL2FjY2Vzcy9oZWFwL2hlYXBhbS5jIGIvc3JjL2Jh
Y2tlbmQvYWNjZXNzL2hlYXAvaGVhcGFtLmMKaW5kZXggODhhMTIzZDM4YS4uNmQzMmQ1YTEz
ZSAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvYWNjZXNzL2hlYXAvaGVhcGFtLmMKKysrIGIv
c3JjL2JhY2tlbmQvYWNjZXNzL2hlYXAvaGVhcGFtLmMKQEAgLTM0ODEsNyArMzQ4MSw3IEBA
IGwyOgogCWVsc2UKIAkJbmVlZF90b2FzdCA9IChIZWFwVHVwbGVIYXNFeHRlcm5hbCgmb2xk
dHVwKSB8fAogCQkJCQkgIEhlYXBUdXBsZUhhc0V4dGVybmFsKG5ld3R1cCkgfHwKLQkJCQkJ
ICBuZXd0dXAtPnRfbGVuID4gVE9BU1RfVFVQTEVfVEhSRVNIT0xEKTsKKwkJCQkJICBuZXd0
dXAtPnRfbGVuID4gMTAwKTsKIAogCXBhZ2VmcmVlID0gUGFnZUdldEhlYXBGcmVlU3BhY2Uo
cGFnZSk7CiAKZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL2FjY2Vzcy90YWJsZS90b2FzdF9o
ZWxwZXIuYyBiL3NyYy9iYWNrZW5kL2FjY2Vzcy90YWJsZS90b2FzdF9oZWxwZXIuYwppbmRl
eCBiNWNmZWIyMWFhLi4yOGNiNzA0MDRjIDEwMDY0NAotLS0gYS9zcmMvYmFja2VuZC9hY2Nl
c3MvdGFibGUvdG9hc3RfaGVscGVyLmMKKysrIGIvc3JjL2JhY2tlbmQvYWNjZXNzL3RhYmxl
L3RvYXN0X2hlbHBlci5jCkBAIC0yMSw2ICsyMSw3IEBACiAjaW5jbHVkZSAiY2F0YWxvZy9w
Z190eXBlX2QuaCIKICNpbmNsdWRlICJ2YXJhdHQuaCIKIAorI2luY2x1ZGUgInV0aWxzL3Nu
YXBtZ3IuaCIKIAogLyoKICAqIFByZXBhcmUgdG8gVE9BU1QgYSB0dXBsZS4KQEAgLTI3OCw2
ICsyNzksNyBAQCB0b2FzdF90dXBsZV9jbGVhbnVwKFRvYXN0VHVwbGVDb250ZXh0ICp0dGMp
CiAJVHVwbGVEZXNjCXR1cGxlRGVzYyA9IHR0Yy0+dHRjX3JlbC0+cmRfYXR0OwogCWludAkJ
CW51bUF0dHJzID0gdHVwbGVEZXNjLT5uYXR0czsKIAorQXNzZXJ0KEhhdmVSZWdpc3RlcmVk
T3JBY3RpdmVTbmFwc2hvdCgpKTsKIAkvKgogCSAqIEZyZWUgYWxsb2NhdGVkIHRlbXAgdmFs
dWVzCiAJICovCg==

--------------T21k0FKoF1J09eVjzD47sjI0--