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
