Re: MultiXact\SLRU buffers configuration

x4mmm@yandex-team.ru

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-10-31T10:46:37Z
Lists: pgsql-hackers

> On 29 Oct 2024, at 21:45, Thom Brown <thom@linux.com> wrote:
> 
> It clearly checks for interrupts, but when I saw this issue happen, it
> wasn't interruptible.

Perhaps, that was different multixacts?
When I was observing this pathology on Standby, it was a stream of different reads encountering different multis.

Either way startup can cancel locking process on it's own. Or is it the case that cancel was not enough, did you actually need termination, not cancel?

Thanks!


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.