Horton

Re: MultiXact\SLRU buffers configuration

x4mmm@yandex-team.ru

View thread View on postgr.es
From: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
To: Thom Brown <thom@linux.com>
Cc: Michael Paquier <michael@paquier.xyz>, Alvaro Herrera <alvherre@alvh.no-ip.org>, vignesh C <vignesh21@gmail.com>, Andrew Borodin <amborodin86@gmail.com>, Yura Sokolov <y.sokolov@postgrespro.ru>, Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@gmail.com>, Gilles Darold <gilles@darold.net>, Alexander Korotkov <aekorotkov@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers mailing list <pgsql-hackers@postgresql.org>
Date: 2024-11-05T14:11:07Z
Lists: pgsql-hackers 

> On 1 Nov 2024, at 00:25, Thom Brown <thom@linux.com> wrote:
> 
> Unfortunately I didn't gather much information when it was occuring, and prioritised getting rid of the process blocking replay. I just attached gdb to it, got a backtrace and then "print ProcessInterrupts()".
> 

Currently I do not see how this wait can result in a deadlock.
But I did observe standby in a pathological sequential scan encountering recent multixact again and again (new each time).
I hope this situation will be alleviated by recent cahnges - now there is not a millisecond wait, but hopefully smaller amount of time.

In v17 we also added injection point test which reproduces reading very recent multixact. If there is a deadlock I hope buildfarm will show it to us.


Best regards, Andrey Borodin.

Commits

  1. Rework new SLRU test with injection points

  2. injection_point: Add injection_points.stats

  3. injection_points: Add initialization of shmem state when loading module

  4. Add injection-point test for new multixact CV usage

  5. Use conditional variable to wait for next MultiXact offset

  6. Improve performance of subsystems on top of SLRU

  7. Adjust VACUUM hastup LP_REDIRECT comments.

  8. Test replay of regression tests, attempt II.