Hello Alvaro and Mihail,
11.12.2025 22:04, Álvaro Herrera wrote:
On 2025-Dec-09, Mihail Nikalayeu wrote:
After some investigation I ended up with a much simpler fix.
It is self-explanatory in code and a commit message.
Yeah, that makes sense. It's what I was trying to say in
https://postgr.es/m/[email protected]
Pushed your patch, thanks.
Thank you for fixing that once again! But it looks like the
"invalid arbiter index list" error is still not completely gone. It was
produced recently by new 010_index_concurrently_upsert test [1]:
364/364 postgresql:test_misc / test_misc/010_index_concurrently_upsert ERROR
22.47s exit status 29
010_index_concurrently_upsert_node.log contains:
2026-01-08 12:59:26.336 CET [1265129][client backend][74/5:0] ERROR: invalid
arbiter index list
2026-01-08 12:59:26.336 CET [1265129][client backend][74/5:0] STATEMENT: INSERT INTO test.tblparted VALUES (13, now())
ON CONFLICT (i) DO UPDATE SET updated_at = now();
I'm able to reproduce it locally when running 10+ instances of the test
in parallel on a pretty slow machine:
...
1 [18:46:52]
1 All tests successful.
1 Files=1, Tests=68, 36 wallclock secs ( 0.53 usr 0.03 sys + 4.06 cusr
3.38 csys = 8.00 CPU)
1 Result: PASS
3 [18:49:23] t/010_index_concurrently_upsert.pl ..
3 Dubious, test returned 29 (wstat 7424, 0x1d00)
3 Failed 1/45 subtests
3 [18:49:23]
3
3 Test Summary Report
3 -------------------
3 t/010_index_concurrently_upsert.pl (Wstat: 7424 (exited 29) Tests: 45
Failed: 1)
3 Failed test: 45
3 Non-zero exit status: 29
3 Parse errors: No plan found in TAP output
3 Files=1, Tests=45, 186 wallclock secs ( 0.40 usr 0.03 sys + 14.82 cusr
16.18 csys = 31.43 CPU)
3 Result: FAIL
With the more verbose error message, I can see:
src/test/modules/test_misc_3/tmp_check/log/010_index_concurrently_upsert_node.log:
2026-01-16 18:46:39.367 UTC [postgres][2047103:8][client backend] [010_index_concurrently_upsert.pl][74/5:0] ERROR:
invalid arbiter index list: list_length(rootResultRelInfo->ri_onConflictArbiterIndexes): 1, list_length(arbiterIndexes):
2, additional_arbiters: 0
The numbers are the same from three failures in a row I observed.
(I can add more debugging and dig deeper, if needed.)
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=adder&dt=2026-01-08%2011%3A55%3A58
Best regards,
Alexander
