Re: pg_stat_replication log positions vs base backups
От | Michael Paquier |
---|---|
Тема | Re: pg_stat_replication log positions vs base backups |
Дата | |
Msg-id | CAB7nPqTVV6k+1diE6K3zzhX6hGrYBfUA2ntr+vLx6aNKj9-khw@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, Dec 16, 2015 at 7:14 PM, Magnus Hagander <magnus@hagander.net> wrote: > On Wed, Dec 16, 2015 at 8:34 AM, Michael Paquier <michael.paquier@gmail.com> > wrote: >> Interesting. I got just today a bug report that is actually a symptom >> that people should be careful about: it is possible that >> pg_stat_replication reports 1/potential for sync_priority/sync_state >> in the case of a WAL sender in "backup" state: a base backup just >> needs to reuse the shared memory slot of a standby that was previously >> connected. Commit 61c7bee of Magnus fixes the issue, just let's be >> careful if there are similar reports that do not include this fix. > > > Hmm. With the fix, it returns "async", right? Yes, it returns async with priority set at 0 after your commit. That's a bit better than the old behavior, still.. > Perhaps it should return either "backup" or NULL, to be even more clear? And > with priority set to NULL? I'd vote for just NULL for both fields. This async/sync status has no real sense for a backup. Thoughts? -- Michael
В списке pgsql-hackers по дате отправления: