Re: WaitEventSet resource leakage
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org, Alexander Lakhin <exclusion@gmail.com>
Date: 2023-11-19T21:09:57Z
Lists: 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;
Commits
-
Fix resource leak when a FDW's ForeignAsyncRequest function fails
- 555276f85940 14.11 landed
- 481d7d1c01c6 15.6 landed
- 501cfd07dac6 16.2 landed
-
Use ResourceOwner to track WaitEventSets.
- 50c67c2019ab 17.0 landed