Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> I don't actually understand how tight synchronization on its own would
> solve the problem. What if the connection to the master is lost? Do you
> kill all queries in the standby before reconnecting?
Sure. So what? They'd have been killed if they individually lost
connections to the master (or the slave), too.
> [ assorted analysis based on WAL contents ]
The problem is all the interactions that are not reflected (historically
anyway) to WAL. We already know about btree page reclamation interlocks
and relcache init files. How many others are there, and how messy and
expensive is it going to be to deal with them?
> If you really think the current approach is unworkable, I'd suggest that
> we fall back to a stop-and-go system, where you either let the recovery
> to progress or allow queries to run, but not both at the same time. But
> FWIW I don't think the situation is that grave.
I might be wrong. I hope for the sake of the project schedule that I am
wrong. But I'm afraid that we will spend several months beavering away
to try to make the current approach solid and user-friendly, and
eventually conclude that it's a dead end. It would be prudent to have
a Plan B; and it looks to me like closed-loop synchronization is the
best Plan B. Putting off all thought about it for the next release
cycle seems like a recipe for a scheduling disaster.
regards, tom lane
