| From: | Ivan Bykov <i(dot)bykov(at)modernsys(dot)ru> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Cc: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
| Subject: | Re: IPC/MultixactCreation on the Standby server |
| Date: | 2025-10-24 14:33:22 |
| Message-ID: | 176131640229.2081918.17921359199828781786.pgcf@coridan.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi, Andrey!
I started reviewing the TAP tests and for the current master (14ee8e6403001c3788f2622cdcf81a8451502dc2),
src/test/modules/test_slru/t/001_multixact.pl reproduces the problem, but we can do it in a more transparent way.
The test should fail on timeout; otherwise, it would be hard to find the source of the problem.
The current state of 001_multixact.pl just leaves the 'mike' node in a deadlock state and
it looks like a very long test that doesn't finish for vague reasons.
I believe that we should provide more comprehensible feedback to developers
by interrupting the deadlock state with a psql timeout. 15 seconds seems safe
enough to distinguish between slow node operation and deadlock issue.
Here is the modified 001_multixact.pl
----
# Verify thet recorded multi is readble, this call must not hang.
# Also note that all injection points disappeared after server restart.
my $timed_out = 0;
$node->safe_psql(
'postgres',
qq{SELECT test_read_multixact('$multi'::xid);},
timeout => 15,
timed_out => \$timed_out);
ok($timed_out == 0, 'recorded multi is readble');
$node->stop;
done_testing();
----
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dmitry Dolgov | 2025-10-24 14:33:41 | Re: Bug in pg_stat_statements |
| Previous Message | Andres Freund | 2025-10-24 14:23:41 | Re: Improving and extending int128.h to more of numeric.c |