Re: pg_stat_replication log positions vs base backups

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pg_stat_replication log positions vs base backups
Дата
Msg-id CAB7nPqSxt96ygwnaOj_3dgB9o_cxDr_Gm5es0WSDAFkDqW9YgQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_stat_replication log positions vs base backups  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: pg_stat_replication log positions vs base backups
Список pgsql-hackers
Дерево обсуждения


On Wed, Nov 25, 2015 at 7:18 PM, Magnus Hagander <magnus@hagander.net> wrote:

On Wed, Nov 25, 2015 at 10:19 AM, Magnus Hagander <magnus@hagander.net> wrote:
Are the values for the log locations really relevant for backup connections? And if they are, we need to document it :) ISTM we are just more or less leaking random data out there?

I'm talking about the actual state=backup connection - not the connection if we're using -x with pg_basebackup. Where we have output like:

state            | backup
sent_location    | 0/0
write_location   | 2/76CE0000
flush_location   | 2/76CC0000
replay_location  | 2/76CBF938

I'm thinking those fields should probably all be NULL for state=backup?

Hm. You would basically get that when a backup WAL sender is reusing the sender of another node that is not here anymore.
 
In particular, it seems that in InitWalSenderSlot, we only initialize the sent location. Perhaps this is needed?

Yes, that would be nice to start with a clean state. At the same time, I am noticing that pg_stat_get_wal_senders() is comparing flush, apply and write directly with 0. I think those should be InvalidXLogRecPtr. Combined with your patch it gives the attached.
--
Michael
Вложения

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

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: custom function for converting human readable sizes to bytes
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: pg_stat_replication log positions vs base backups