Re: MultiXact\SLRU buffers configuration
| От | Thom Brown |
|---|---|
| Тема | Re: MultiXact\SLRU buffers configuration |
| Дата | |
| Msg-id | CAA-aLv7-fs32r7v8znJ=uPPtQNqZ9_sH2REn=cu1pyEQ=tuEhw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: MultiXact\SLRU buffers configuration ("Andrey M. Borodin" <x4mmm@yandex-team.ru>) |
| Ответы |
Re: MultiXact\SLRU buffers configuration
|
| Список | pgsql-hackers |
On Thu, 31 Oct 2024, 17:33 Andrey M. Borodin, <x4mmm@yandex-team.ru> wrote:
> On 31 Oct 2024, at 17:29, Thom Brown <thom@linux.com> wrote:
>
> On Thu, 31 Oct 2024 at 10:47, Andrey M. Borodin <x4mmm@yandex-team.ru> wrote:
>>
>>
>>
>>> 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?
>
> Termination didn't work on either of the processes.
How did you force the process to actually terminate?
Did you observe repeated read of the same multixact?
Was offending process holding any locks while waiting?
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()".
Thom
В списке pgsql-hackers по дате отправления: