Re: IPC/MultixactCreation on the Standby server

On 02/12/2025 15:44, Andrey Borodin wrote:
>> On 1 Dec 2025, at 20:29, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>>
>> I'm looking through patchsets. I'll look in the morning with fresh eyes.
>
> So far I have no findings.
> I also tried to stress-test v14. I assumed that if regression slipped in, most probably it is inherited by 14 from higher versions.

Thanks! Agreed, v14-16 were the same. v17 and v18 might be worth testing
separately, to make sure I didn't e.g. screw up the locking differences.

> I used slightly modified scripts from Dmitry who started this thread.
>
> DB initialization:
> create table tbl2 (id int primary key,val int);
> insert into tbl2 select i, 0 from generate_series(1,100000) i;
>
> Load with multi:
> \set id random(1, 10000)
> begin;
> select * from tbl2 where id = :id for no key update;
> savepoint s1;
> update tbl2 set val = val+1 where id = :id;
> commit;
>
> Consistency test:
> select sum(val) from tbl2;
>
> Stress-test script:
> while true; do pkill -9 postgres; ./pg_ctl -D testdb restart; (./pgbench --no-vacuum -M prepared -c 50 -j 4 -T 300 -P 1 postgres --file=load.sql &); sleep 5; done
>
> To promote multixact races I tried this with patched version: added random sleep up to 50ms between GetNewMultiXactId() and RecordNewMultiXact().
>
> So far I did not manage to corrupt database.
>
> What else kind of loads worth exercising?

Combinations of patched and unpatched binaries, as primary/replica and
crash recovery. I did some testing of crash recovery, but more would be
good.

- Heikki