Re: Strange failure in LWLock on skink in REL9_5_STABLE
Thomas Munro <thomas.munro@enterprisedb.com>
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-09-21T20:54:57Z
Lists: pgsql-hackers
On Fri, Sep 21, 2018 at 4:43 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.munro@enterprisedb.com> writes: > > On Fri, Sep 21, 2018 at 4:06 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Why would we fix it rather than just removing it? > > > I assumed we wouldn't remove an extern C function extension code > > somewhere might use. Though admittedly I'd be surprised if anyone > > used this one. > > Unless it looks practical to support this behavior in the Windows > and SysV cases, I think we should get rid of it rather than expend > effort on supporting it for just some platforms. We can remove it in back-branches without breaking API compatibility: 1. Change dsm_impl_can_resize() to return false unconditionally (I suppose client code is supposed to check this before using dsm_resize(), though I'm not sure why it has an "impl" in its name if it's part of the public interface of this module). 2. Change dsm_resize() and dsm_remap() to raise an error conditionally. 3. Rip out the DSM_OP_RESIZE cases from various places. Then in master, remove all of those functions completely. However, I'd feel like a bit of a vandal. Robert and Amit probably had plans for that code...? -- Thomas Munro http://www.enterprisedb.com
Commits
-
Remove some remaining traces of dsm_resize().
- 9e12fb02b7ec 12.0 landed
-
Remove dsm_resize() and dsm_remap().
- 3c60d0fa231f 12.0 landed
-
Allow DSM allocation to be interrupted.
- fb389498be5c 9.5.15 cited