Re: Strange failure in LWLock on skink in REL9_5_STABLE
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-11-05T07:28:09Z
Lists: pgsql-hackers
On Tue, Sep 25, 2018 at 06:22:19PM +1200, Thomas Munro wrote: > On Sat, Sep 22, 2018 at 4:52 PM Amit Kapila <amit.kapila16@gmail.com> wrote: >> I went through and check the original proposal [1] to see if any use >> case is mentioned there, but nothing related has been discussed. I >> couldn't think of much use of this facility except maybe for something >> like parallelizing correalated sub-queries where the size of outer var >> can change across executions and we might need to resize the initially >> allocated memory. This is just a wild thought, I don't have any >> concrete idea about this. Having said that, I don't object to >> removing this especially because the implementation doesn't seem to be >> complete. In future, if someone needs such a facility, they can first >> develop a complete version of this API. > > Thanks for looking into that. Here's a pair of draft patches to > disable and then remove dsm_resize() and dsm_map(). 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. -- Michael
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