Re: [HACKERS] src/test/subscription/t/002_types.pl hanging onparticular environment

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: [HACKERS] src/test/subscription/t/002_types.pl hanging onparticular environment
Дата
Msg-id CAMsr+YGGb8LwgD8vcBYdiepmdJSMBVAFekHm8cWnxifYZy9O=g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] src/test/subscription/t/002_types.pl hanging on particular environment  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] src/test/subscription/t/002_types.pl hanging onparticular environment  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-hackers
On 20 September 2017 at 11:53, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Craig Ringer <craig@2ndquadrant.com> writes:
> On 19 September 2017 at 18:04, Petr Jelinek <petr.jelinek@2ndquadrant.com>
> wrote:
>> If you are asking why they are not identified by the
>> BackgroundWorkerHandle, then it's because it's private struct and can't
>> be shared with other processes so there is no way to link the logical
>> worker info with bgworker directly.

> I really want BackgroundWorkerHandle to be public, strong +1 from me.

I'm confused about what you think that would accomplish.  AFAICS, the
point of BackgroundWorkerHandle is to allow the creator/requestor of
a bgworker to verify whether or not the slot in question is still
"owned" by its request.  This is necessarily not useful to any other
process, since they didn't make the request.

I'm using shm_mq in a sort of "connection accepter" role, where a pool of shm_mq's are attached to by a long lived bgworker. Other backends, both bgworkers and normal user backends, can find a free slot and attach to it to talk to the long lived bgworker. These other backends are not necessarily started by the long lived worker, so it doesn't have a BackgroundWorkerHandle for them.

Currently, if the long lived bgworker dies and a peer attempts to attach to the slot, they'll hang forever in shm_mq_wait_internal, because it cannot use shm_mq_set_handle as described in https://www.postgresql.org/message-id/E1XbwOs-0002Fd-H9%40gemulon.postgresql.org to protect its self.


If the BackgroundWorkerHandle for the long-lived bgworker is copied to a small static control shmem segment, the connecting workers can use that to reliably bail out if the long-lived worker dies.
 
The thought I had in mind upthread was to get rid of logicalrep slots
in favor of expanding the underlying bgworker slot with some additional
fields that would carry whatever extra info we need about a logicalrep
worker.  Such fields could also be repurposed for additional info about
other kinds of bgworkers, when (not if) we find out we need that.

That sounds OK to me personally for in-core logical rep, but it's really Petr and Peter who need to have a say here, not me.
 
--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] why not parallel seq scan for slow functions
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Re: [COMMITTERS] pgsql: Make new crash restart test abit more robust.