Re: pg_receivewal starting position

Поиск
Список
Период
Сортировка
От Bharath Rupireddy
Тема Re: pg_receivewal starting position
Дата
Msg-id CALj2ACXw2KHmt01eQaNzvbnWQiVZ8GSKCpeGGw3UivoOTQ=4jA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_receivewal starting position  (Ronan Dunklau <ronan.dunklau@aiven.io>)
Ответы Re: pg_receivewal starting position  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers
On Mon, Aug 30, 2021 at 3:26 PM Ronan Dunklau <ronan.dunklau@aiven.io> wrote:
> > 7) How about we let pg_receivewal use READ_REPLICATION_SLOT as an option?
>
> From my point of view, I already expected it to use something like that when
> using a replication slot. Maybe an option to turn it off could be useful ?

IMO, pg_receivewal should have a way to turn off/on using
READ_REPLICATION_SLOT. Imagine if the postgres server doesn't support
READ_REPLICATION_SLOT (a lower version) but for some reasons the
pg_receivewal(running separately) is upgraded to the version that uses
READ_REPLICATION_SLOT, knowing that the server doesn't support
READ_REPLICATION_SLOT why should user let pg_receivewal run an
unnecessary code?

Regards,
Bharath Rupireddy.



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Allow escape in application_name (was: [postgres_fdw] add local pid to fallback_application_name)