From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_receivexlog and feedback message |
Date: | 2012-06-05 14:42:23 |
Message-ID: | CAHGQGwHwok-3_isC8+M+tz6DeRks18tUfnJgfkQ_um0-DJyUxg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 5, 2012 at 9:53 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> Right now, pg_receivexlog sets:
> replymsg->write = InvalidXLogRecPtr;
> replymsg->flush = InvalidXLogRecPtr;
> replymsg->apply = InvalidXLogRecPtr;
>
> when it sends it's status updates.
>
> I'm thinking it sohuld set replymsg->write = blockpos instad.
>
> Why? That way you can see in pg_stat_replication what has actually
> been received by pg_receivexlog - not just what we last sent. This can
> be useful in combination with an archive_command that can block WAL
> recycling until it has been saved to the standby. And it would be
> useful as a general monitoring thing as well.
>
> I think the original reason was that it shouldn't interefer with
> synchronous replication - but it does take away a fairly useful
> usecase...
I think that not only replaymsg->write but also ->flush should be set to
blockpos in pg_receivexlog. Which allows pg_receivexlog to behave
as synchronous standby, so we can write WAL to both local and remote
synchronously. I believe there are some use cases for synchronous
pg_receivexlog.
OTOH, neither replaymsg->write nor ->flush should be set to
InvalidXLogRecPtr, to prevent pg_basebackup from behaving as
synchronous standby.
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2012-06-05 14:42:31 | Re: incorrect handling of the timeout in pg_receivexlog |
Previous Message | Fujii Masao | 2012-06-05 14:28:39 | Re: incorrect handling of the timeout in pg_receivexlog |