Re: [HACKERS] pg_basebackup behavior on non-existent slot

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [HACKERS] pg_basebackup behavior on non-existent slot
Дата
Msg-id CABUevEyoHy+z=E1sMt6FXcoxu8Uq16qqYyBGYLLm5kBnhwTPdA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] pg_basebackup behavior on non-existent slot  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
Дерево обсуждения
On Wed, Sep 6, 2017 at 11:50 AM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
Magnus Hagander wrote:
> On Mon, Sep 4, 2017 at 3:21 PM, Jeff Janes <jeff.janes@gmail.com> wrote:

> > Should the parent process of pg_basebackup be made to respond to SIGCHLD?
> > Or call waitpid(bgchild, &status, WNOHANG) in some strategic loop?
>
> I think it's ok to just call waitpid() -- we don't need to react super
> quickly, but we should react.

Hmm, not sure about that ... in the normal case (slotname is correct)
you'd be doing thousands of useless waitpid() system calls during the
whole operation, no?  I think it'd be better to have a SIGCHLD handler
that sets a flag (just once), which can be quickly checked without
accessing kernel space.

Good point.

So the question is what to do for Windows. I'd rather not have to bring in the whole extra thread and socket emulation stuff into pg_basebackup if it can be avoided. But I guess we could code up something Windows-specific in just that one (since it's threaded and not processed on Windows, it's easier than the backend). I think that means we'd have to rewrite it to use the async libpq apis, don't you?

The other option would be to just kill the process from the child thread. Since the're threads we can do that. However, that will leave us in a position where we can't clean up from the error (as in remove files/dirs), not sure that's good?


--

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

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: [HACKERS] Walsender timeouts and large transactions
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] Partition-wise join for join between (declaratively)partitioned tables