Re: [HACKERS] Support for pg_receivexlog --post-segment command

Поиск
Список
Период
Сортировка
От Feike Steenbergen
Тема Re: [HACKERS] Support for pg_receivexlog --post-segment command
Дата
Msg-id CAK_s-G3z=2X80w7h9JYdRZm2xA=ZkrN82HdGjc+d9zQMbAZvOQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Support for pg_receivexlog --post-segment command  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: [HACKERS] Support for pg_receivexlog --post-segment command  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
On 6 January 2017 at 13:50, Magnus Hagander <magnus@hagander.net> wrote:
> I think we're better off clearly documenting that we don't care about it. And basically let the external command be responsible for that part.

> So for example, your typical backup manager would listen to this signal or whatever to react quickly. But it would *also* have some sort of fallback. For example, whenever it's triggered it also checks if there are any previous segments it missed (this would also cover the startup sequence).

For me this works fine. I just want to ensure that if there is any work to be done, my backup manager will do the work quickly. My implementation might be very simply a process that checks every n seconds or when signalled.

> Since we never actually remove anything (unlike archive_command which has the integration with wal segment rotation), I think this can be done perfectly safe.
>
> Looking at the usecases where you have been doing it, are there any where this would not work?

This would work for all usecases I've come across.

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

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: Re: [HACKERS] postgres_fdw bug in 9.6
Следующее
От: Ashutosh Sharma
Дата:
Сообщение: Re: [HACKERS] Add pgstathashindex() to get hash index table statistics.