Re: IPC/MultixactCreation on the Standby server
| От | Andrey Borodin |
|---|---|
| Тема | Re: IPC/MultixactCreation on the Standby server |
| Дата | |
| Msg-id | 6A068D1B-62AF-4673-91FD-DCD9E3303023@yandex-team.ru обсуждение исходный текст |
| Ответ на | Re: IPC/MultixactCreation on the Standby server (Andrey Borodin <x4mmm@yandex-team.ru>) |
| Ответы |
Re: IPC/MultixactCreation on the Standby server
|
| Список | pgsql-hackers |
> On 1 Dec 2025, at 20:29, Andrey Borodin <x4mmm@yandex-team.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 higherversions. 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() andRecordNewMultiXact(). So far I did not manage to corrupt database. What else kind of loads worth exercising? Best regards, Andrey Borodin.
В списке pgsql-hackers по дате отправления: