Horton
Menu

Re: IPC/MultixactCreation on the Standby server

Ivan Bykov <i.bykov@modernsys.ru>

View thread
From: Ivan Bykov <i.bykov@modernsys.ru>
To: pgsql-hackers@lists.postgresql.org
Cc: Andrey Borodin <x4mmm@yandex-team.ru>
Date: 2025-10-24T14:33:22Z
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();
----

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix test to work with non-8kB block sizes

  2. Fix setting next multixid's offset at offset wraparound

  3. Add test for multixid wraparound

  4. Set next multixid's offset when creating a new multixid

  5. psql: Improve tab completion for large objects.

  6. Refactor some repetitive SLRU code

  7. Transaction IDs wrap around, per my proposal of 13-Aug-01. More