Greg Smith wrote:
> 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.
I suspect the master could connect to the slave to pull an xid.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.comPG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard
drive,Christ can be your backup. +
