Re: pg_stat_replication log positions vs base backups
От | Magnus Hagander |
---|---|
Тема | Re: pg_stat_replication log positions vs base backups |
Дата | |
Msg-id | CABUevEyJ9CP0PBCCRF5B5fqkdwoaaD7GsrO2F0gCfQX-MbRPUQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_stat_replication log positions vs base backups (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: pg_stat_replication log positions vs base backups
|
Список | pgsql-hackers |
On Wed, Nov 25, 2015 at 3:03 PM, Michael Paquier <michael.paquier@gmail.com> wrote:
-- 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 | backupsent_location | 0/0write_location | 2/76CE0000flush_location | 2/76CC0000replay_location | 2/76CBF938I'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.
Yeah - and that's obviously incorrect.
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.
Good point.
Another thought - why do we leave 0/0 in sent location, but turn the other three fields to NULL if it's invalid? That seems inconsistent. Is there a reason for that, or should we fix that as well while we're at it?
В списке pgsql-hackers по дате отправления: