Hi,
Simon Riggs wrote:
> The second way can be done by taking a snapshot on the primary, with an
> associated LSN, then using that snapshot on the standby. That is
> somewhat complex, but possible. I see the requirement for getting the
> same answer on multiple nodes as a further extension of "transaction
> isolation mode" and think that not all people will want this, so we
> should allow that as an option.
I've been thinking a bit about this pretty interesting idea. It's
certainly of interest for Postgres-R as well.
AFAIK a function could simply wait, until the node which is being
queried reaches a given point in time of application of transactions (an
LSN, in the Sync-Rep world). Calling such a waiting function just after
BEGIN would ensure to see (at least) the given snapshot. If that
snapshot has already been reached or passed, the function does nothing.
What I like is, that it's optimistic in that the wait is only enforced
when needed by the reader. However, unlike enforcing the wait before
COMMIT, it requires changing the application to cope with this behavior
of the distributed database system. And knowing when to require which
snapshot sounds rather difficult from the point of view of the
application developer.
Also note, that it might be the issuer of the transaction who wants to
ensure "his" transaction got propagated to the remote nodes.
> I'm not going to worry about this at the moment. Hot standby will be
> useful without this and so I regard this as a secondary objective. Rome
> wasn't built in a single release, or something like that.
Sounds like a decent plan. Good luck.
Regards
Markus Wanner