From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_stat_replication log positions vs base backups |
Date: | 2015-12-16 12:35:50 |
Message-ID: | CAB7nPqTVV6k+1diE6K3zzhX6hGrYBfUA2ntr+vLx6aNKj9-khw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 16, 2015 at 7:14 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Wed, Dec 16, 2015 at 8:34 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2015-12-16 12:49:23 | Re: parallel joins, and better parallel explain |
Previous Message | Robert Haas | 2015-12-16 12:34:25 | Re: [PoC] Asynchronous execution again (which is not parallel) |