Re: WaitEventSet resource leakage

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Alexander Lakhin <exclusion(at)gmail(dot)com>
Subject: Re: WaitEventSet resource leakage
Date: 2023-11-19 21:09:57
Message-ID: CA+hUKGLHREy3DEq0R_soxE_T8iu4NPbY6TaEwA0uVCayvKUL0w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 17, 2023 at 12:22 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> On 16/11/2023 01:08, Tom Lane wrote:
> > Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> >> On 09/03/2023 20:51, Tom Lane wrote:
> >>> After further thought that seems like a pretty ad-hoc solution.
> >>> We probably can do no better in the back branches, but shouldn't
> >>> we start treating WaitEventSets as ResourceOwner-managed resources?
> >>> Otherwise, transient WaitEventSets are going to be a permanent
> >>> source of headaches.
> >
> >> Let's change it so that it's always allocated in TopMemoryContext, but
> >> pass a ResourceOwner instead:
> >> WaitEventSet *
> >> CreateWaitEventSet(ResourceOwner owner, int nevents)
> >> And use owner == NULL to mean session lifetime.
> >
> > WFM. (I didn't study your back-branch patch.)
>
> And here is a patch to implement that on master.

Rationale and code look good to me.

cfbot warns about WAIT_USE_WIN32:

[10:12:54.375] latch.c:889:2: error: ISO C90 forbids mixed
declarations and code [-Werror=declaration-after-statement]

Let's see...

WaitEvent *cur_event;

for (cur_event = set->events;

Maybe:

for (WaitEvent *cur_event = set->events;

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2023-11-19 22:00:14 Re: On non-Windows, hard depend on uselocale(3)
Previous Message Tomas Vondra 2023-11-19 20:12:44 Re: XX000: tuple concurrently deleted during DROP STATISTICS