Re: Trap errors from streaming child in pg_basebackup to exit early

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: Trap errors from streaming child in pg_basebackup to exit early
Дата
Msg-id AC3D81D5-766E-4894-B429-912F8257BE9E@yesql.se
обсуждение исходный текст
Ответ на Re: Trap errors from streaming child in pg_basebackup to exit early  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Ответы Re: Trap errors from streaming child in pg_basebackup to exit early  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Re: Trap errors from streaming child in pg_basebackup to exit early  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
> On 1 Sep 2021, at 12:28, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote:
>
> On Wed, Sep 1, 2021 at 1:56 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>> A v2 with the above fixes is attached.
>
> Thanks for the updated patch. Here are some comments:
>
> 1) Do we need to set bgchild = -1 before the exit(1); in the code
> below so that we don't kill(bgchild, SIGTERM); unnecessarily in
> kill_bgchild_atexit?

Good point. We can also inspect bgchild_exited in kill_bgchild_atexit.

> 2) Missing "," after "On Windows, we use a ....."
> + * that time. On Windows we use a background thread which can communicate
>
> 3) How about "/* Flag to indicate whether or not child process exited
> */" instead of +/* State of child process */?

Fixed.

> 4) Instead of just exiting from the main pg_basebackup process when
> the child WAL receiver dies, can't we think of restarting the child
> process, probably with the WAL streaming position where it left off or
> stream from the beginning? This way, the work that the main
> pg_basebackup has done so far doesn't get wasted. I'm not sure if this
> affects the pg_basebackup functionality. We can restart the child
> process for 1 or 2 times, if it still dies, we can kill the main
> pg_baasebackup process too. Thoughts?

I was toying with the idea, but I ended up not pursuing it.  This error is well
into the “really shouldn’t happen, but can” territory and it’s quite likely
that some level of manual intervention is required to make it successfully
restart.  I’m not convinced that adding complicated logic to restart (and even
more complicated tests to simulate and test it) will be worthwhile.

--
Daniel Gustafsson        https://vmware.com/


Вложения

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Added schema level support for publication.
Следующее
От: Ronan Dunklau
Дата:
Сообщение: Re: pg_receivewal starting position