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

From Tom Lane
Subject Re: Fixing order of resowner cleanup in 12, for Windows
Date
Msg-id 24546.1556806511@sss.pgh.pa.us
Whole thread Raw
In response to Fixing order of resowner cleanup in 12, for Windows  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Fixing order of resowner cleanup in 12, for Windows  (Thomas Munro <thomas.munro@gmail.com>)
Re: Fixing order of resowner cleanup in 12, for Windows  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> A while back I posted a patch[1] to change the order of resowner
> cleanup so that DSM handles are released last.  That's useful for the
> error cleanup path on Windows, when a SharedFileSet is cleaned up (a
> mechanism that's used by parallel CREATE INDEX and parallel hash join,
> for spilling files to disk under a temporary directory, with automatic
> cleanup).

I guess what I'm wondering is if there are any potential negative
consequences, ie code that won't work if we change the order like this.
I'm finding it hard to visualize what that would be, but then again
this failure mode wasn't obvious either.

> I suppose we probably should make the change to 12 though: then owners
> of extensions that use DSM detach hooks (if there any such extensions)
> will have a bit of time to get used to the new order during the beta
> period.  I'll need to find someone to test this with a fault injection
> scenario on Windows before committing it, but wanted to sound out the
> list for any objections to this late change?

Since we haven't started beta yet, I don't see a reason not to change
it.  Worst case is that it causes problems and we revert it.

I concur with not back-patching, in any case.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Inconsistent error message wording for REINDEX CONCURRENTLY
Next
From: Robert Haas
Date:
Subject: Re: New vacuum option to do only freezing