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: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
Amit Kapila <amit.kapila16@gmail.com>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-11-06T04:29:36Z
Lists: pgsql-hackers
On Tue, Nov 6, 2018 at 10:18 AM Robert Haas <robertmhaas@gmail.com> wrote: > On Mon, Nov 5, 2018 at 2:28 AM Michael Paquier <michael@paquier.xyz> wrote: > > Hm. Don't we need to worry about anybody potentially using these APIs > > in a custom module on platforms where it was actually working? I > > imagine that their reaction is not going be nice if any code breaks > > suddenly after a minor release. No issues with removing the interface > > on HEAD of course. > > +1. > > The fact that the code exists there at all is my fault. I thought it > might be useful someday, but now I don't think so any more. Thomas's > solution -- in the DSA machinery -- of allocating entirely new > segments seems like a better approach for now, and in the long run, I > think we should convert the whole backend to use threads, > nonwithstanding the TODO entry that says otherwise. Even if we never > do that, extending a segment in place is pretty difficult to make > practical, since it may involve remapping the segment, which > invalidates cached pointers to anything in the segment. And then > there are the portability problems on top of that. So I'm not very > optimistic about this any more. > > But ripping it out in the back branches seems unnecessary. I'd just > leave the bugs unfixed there. Most likely nobody is using that stuff, > but if they are, let's not break it. Thanks. Pushed to master only. -- 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