> On 21 Jul 2025, at 19:58, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>
> I'm planning to prepare tests and fixes for all supported branches
This is a status update message. I've reproduced problem on REL_13_STABLE and verified that proposed fix works there.
Also I've discovered one more serious problem.
If a backend crashes just before WAL-logging multi, any heap tuple that uses this multi will become unreadable. Any
attemptto read it will hang forever.
I've reproduced the problem and now I'm working on scripting this scenario. Basically, I modify code to hang forever
afterassigning multi number 2. Then execute in first psql:
create table x as select i,0 v from generate_series(1,10) i;
create unique index on x(i);
\set id 1
begin;
select * from x where i = :id for no key update;
savepoint s1;
update x set v = v+1 where i = :id; -- multi 1
commit;
\set id 2
begin;
select * from x where i = :id for no key update;
savepoint s1;
update x set v = v+1 where i = :id; -- multi 2 -- will hang
commit;
Then in second psql:
create table y as select i,0 v from generate_series(1,10) i;
create unique index on y(i);
\set id 1
begin;
select * from y where i = :id for no key update;
savepoint s1;
update y set v = v+1 where i = :id;
commit;
After this I pkill -9 postgres. Recovered installation cannot execute select * from x; because multi 1 cannot be read
withoutrecovery of multi 2 which was never logged.
Luckily fix is the same: just restore offset of multi 2 when multi 1 is recovered.
Best regards, Andrey Borodin.
