On 2015-03-26 11:57, Craig Ringer wrote:
If that's the case then BDR shouldn't make any difference.
It does. Because now with BDR you can't compare txid_current() as saved
on the master with txid_snapshot_xmin() as read by the replica.
If however, you could save the txid associated with the application of
the BDR replication on the target, you would again be able to compare.
Earlier you were speaking of (presumably not synchronous) streaming
replicas, and writes on the master vs reads from the replica, and a
way you avoid caching stale data from the read-replica using the
application's cache manager to co-ordinate visibility horizons. It
sounded like you were looking for a way to translate that into
something that could work with BDR. Did I misunderstand?
No. I think you understood, but the goal of using txid from the master
was not to co-ordinate with the master. Only to match changes on the
slave with reads on the slave.
The extra property of txid's being the same on the master was not used.
The problem when using BDR is that the "slave" has it's own txid
sequence and I can't get the txid of all transactions doing changes, -
since some of them are via BDR and doesn't cause triggers.
One way to handle that is to SELECT ... FOR SHARE in your reads, then
update the cache and not commit until the cache has been updated.
A concurrent UPDATE can then not proceed until the cache write has been
completed.
Yes, that would serialize the selects...
It's very complicated to integrate into the cache however, since it
doesn't really know about how the values to cache are retrieved.
/Peter
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
