Heikki Linnakangas wrote:
> One such landmine is that the keepalives need to flow from client to
> server while the WAL records are flowing from server to client. We'll
> have to crack that problem for synchronous replication too, but I think
> that alone is a big enough problem to make this 9.1 material.
>
This seems to be the real sticking point then, given that the
xmin/PGPROC side on the master seems logically straightforward. For
some reason I thought the sync rep feature had the reverse message flow
already going, and that some other sort of limitation just made it
impractical to merge into the main codebase this early. My hope was
that just this particular part could get cherry-picked out of there, and
that it might even have been thought about already in that context given
the known HS keepalive "serious issue". If there was a solution or
partial solution in progress to that floating around, my thought was
that just piggybacking this extra xid info on top of it would be easy
enough.
If there's not already a standby to primary communications backchannel
implementation available that can be harvested from that work, your
suggestion that this may not be feasible at all for 9.0 seems like a
more serious concern than I had thought it was going to be.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us
