When starting pg_receivexlog for the first time, i.e. with an empty
directory, it sometimes fails like this:
pg_receivexlog: unexpected termination of replication stream: ERROR:
requested starting point 56/70000000 is ahead of the WAL flush position
of this server 56/6FFC4000
This is easier to reproduce if you have a steady stream of updates, with
no commits, running concurrently. A bulk load, for example.
The problem is that pg_receivexlog issues the IDENTIFY_SYSTEM command,
which returns the current WAL insert position. It then requests to start
streaming from that position. Or to be precise, from the beginning of
the WAL segment containing that position. That's wrong; the WAL might
not be flushed up to the insert position yet.
I think returning the insert position in IDENTIFY_SYSTEM is a bad idea.
We even mention in the documentation that that field is "useful to get a
known location in the transaction log where streaming can start", but
the insert position is wrong for that purpose.
Any objections to changing IDENTIFY_SYSTEM to return the flush position,
instead of insert position? We haven't heard any complaints from the
field about this, but IMHO that should also be back-patched. It's a
design bug, and the fix is simple and unlikely to cause any harm.
- Heikki
