Re: Strange failure in LWLock on skink in REL9_5_STABLE

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Strange failure in LWLock on skink in REL9_5_STABLE
Дата
Msg-id CAEepm=1NMvxKPuc3+9Om294rzEH4Ck4DjdUEkB8o7SH1qn1n1A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Strange failure in LWLock on skink in REL9_5_STABLE  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Strange failure in LWLock on skink in REL9_5_STABLE  (Andres Freund <andres@anarazel.de>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Strange failure in LWLock on skink in REL9_5_STABLE