Re: WaitEventSet resource leakage - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: WaitEventSet resource leakage
Date
Msg-id CA+hUKGLHREy3DEq0R_soxE_T8iu4NPbY6TaEwA0uVCayvKUL0w@mail.gmail.com
Whole thread Raw
In response to Re: WaitEventSet resource leakage  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: WaitEventSet resource leakage
List pgsql-hackers
On Fri, Nov 17, 2023 at 12:22 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> On 16/11/2023 01:08, Tom Lane wrote:
> > Heikki Linnakangas <hlinnaka@iki.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;



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: XX000: tuple concurrently deleted during DROP STATISTICS
Next
From: Thomas Munro
Date:
Subject: Re: On non-Windows, hard depend on uselocale(3)