On Tue, Aug 23, 2016 at 7:34 AM, Gabriele Bartolini
<gabriele.bartolini@2ndquadrant.it> wrote:
> Looking up the code in more details I see that, unless replication slot
> are enabled, pg_receivexlog does not report the flush position (this is a
> precaution that's been taken when '--synchronous' was probably not around).
> Please find this very short patch which - in case replication slots are not
> present but synchronous is - reports the flush position.
Ouch.
> I am not sure if it is a bug or not. I any case I guess we should
> probably improve the documentation - it's a bit late here so maybe I can try
> better tomorrow with a fresher mind. :)
Looking at c4f99d20, there is the following thing from the commit log:
This commit removes -F option from and adds --synchronous to pg_receivexlog.
If --synchronous is specified, like the standby's wal receiver, pg_receivexlog
flushes WAL data as soon as there is WAL data which has not been flushed yet.
Then it sends back the feedback message identifying the latest flush location
to the server. This option is useful to make pg_receivexlog behave as sync
standby by using replication slot, for example.
The docs also clearly state what --sync should do:
Also send a status packet back to the server immediately after
flushing, regardless of --status-interval.
So it means that you are right, this is a bug and we should report the
flush position back to the server so as pg_receivexlog can be thought
as a synchronous replica. Looking at your patch, I think that this is
the right shot, but I don't think that the first comment block should
be completely removed as it still applies when replication slots are
enabled. I'd suggest rewording it a bit instead, please see attached.
And of course this needs a backpatch.
--
Michael