Re: pgsql: Add function to log the memory contexts of specified backend pro
От | torikoshia |
---|---|
Тема | Re: pgsql: Add function to log the memory contexts of specified backend pro |
Дата | |
Msg-id | d7d7364d149587e5da2299f7acbc90dc@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: pgsql: Add function to log the memory contexts of specified backend pro (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: pgsql: Add function to log the memory contexts of specified backend pro
|
Список | pgsql-hackers |
On 2025-05-02 09:02, Fujii Masao wrote: > On 2025/05/02 2:27, Fujii Masao wrote: >> >> >> On 2025/05/01 21:42, Robert Haas wrote: >>> On Thu, May 1, 2025 at 3:53 AM Fujii Masao >>> <masao.fujii@oss.nttdata.com> wrote: >>>> Just idea, what do you think about adding a flag to indicate whether >>>> ProcessLogMemoryContextInterrupt() is currently running? Then, >>>> when a backend receives a signal and >>>> ProcessLogMemoryContextInterrupt() >>>> is invoked, it can simply return immediately if the flag is already >>>> set >>>> like this: >>> >>> I think that something like this could work, but you would need more >>> than this. Otherwise, if the function errors out, the flag would >>> remain permanently set. >> >> Yes, we need to either use PG_TRY()/PG_FINALLY() or handle the flag as >> a global variable and reset it in the error handling path. I think >> using >> PG_TRY()/PG_FINALLY() is the simpler option. > > I've implemented the patch in that way. Patch attached. Thank you for the patch! I confirmed that with this patch applied, the process no longer crashes even after applying the change Robert used to trigger the crash. a small nitpick: + * requested repeatedly and rapidly, potentially leading to infinite It looks like there are two spaces between "requested" and "repeatedly". -- Regards, -- Atsushi Torikoshi Seconded from NTT DATA GROUP CORPORATION to SRA OSS K.K.
В списке pgsql-hackers по дате отправления: