Re: Fixing order of resowner cleanup in 12, for Windows - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Fixing order of resowner cleanup in 12, for Windows
Date
Msg-id CA+hUKG+ZrjZgEcDrffaggkgnBtShsHsf68qUoLYa7Dm6BaoO-Q@mail.gmail.com
Whole thread Raw
In response to Re: Fixing order of resowner cleanup in 12, for Windows  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fixing order of resowner cleanup in 12, for Windows  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, May 6, 2019 at 11:07 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> One thing I don't care for about this patch is that the original code
> looked like it didn't matter what order we did the resource releases in,
> and the patched code still looks like that.  You're not doing future
> hackers any service by failing to include a comment that explains that
> DSM detach MUST BE LAST, and explaining why.  Even with that, I'd only
> rate it about a 75% chance that somebody won't try to add their new
> resource type at the end --- but with no comment, the odds they'll
> get it right are indistinguishable from zero.

Ok, here's a version that provides a specific reason (the Windows file
handle thing) and also a more general reasoning: we don't really want
extension (or core) authors writing callbacks that depend on eg pins
or locks or whatever else being still held when they run, because
that's fragile, so calling them last is the best and most conservative
choice.  I think if someone does come with legitimate reasons to want
that, we should discuss it then, and perhaps consider something a bit
like the ResourceRelease_callbacks list: its callbacks are invoked for
each phase.


--
Thomas Munro
https://enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Steve
Date:
Subject: pg_ssl_init
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] Weaker shmem interlock w/o postmaster.pid