On 2015-03-26 12:56, Craig Ringer wrote:
My comment was with regards to it being on the local node. A master and synchronous replica isn't a local-node to local-node scenario.
No. But all I'm exploiting is that change events to the local node see the same logical clock as SELECT statements to the same node.
As previously mentioned it's likely to be possible to add per-row apply callbacks that can be written in plpgsql or other function languages, but no such feature currently exists in BDR.
I'll put it on my wish list then :)
Firing real "FOR EACH ROW ... ENABLE REPLICA" triggers may also be possible, but I haven't done any significant looking into it, and I'd be concerned about the correctness of doing so for row triggers but not statement triggers.
That too :)
One issue is that it'd probably have to be able to restrict writes to unlogged tables or tables that aren't part of a replication set. If it could write to replicated tables it'd be doing so in the context of the apply worker, so the writes would not get replicated to other nodes. That'd mean the triggers would be creating rows only on one node - and that's a fast track to data divergence that can cause replication stalls and so on.
For the use case at hand, that's not a problem. The trigger would only need to update a fully local state. - like a table not part of the replication set and not related to any other tables. - like an FIFO queue of invalidation events.
/Peter -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
