Re: BDR - triggers on receiving node?

From: Peter Mogensen <apm(at)one(dot)com>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: BDR - triggers on receiving node?
Date: 2015-03-26 14:36:09
Message-ID: 55141959.8060800@one.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 2015-03-26 12:56, Craig Ringer wrote:
> At this point I think commit timestamps are likely to be your best
> bet, and certainly what you should start looking into first.

I've thought about this, but it seems that since these timestamps are
made on the node doing the change and you have no way on knowing if one
node in the cluster is far behind in it's replication to you, then you
could make a select on the local node being much newer in timestamp than
the transaction changing the value - which would only arrive later (and
making pg_get_latest_transaction_committime_data() go backwards).

But I think I might have found a way to make this work with BDR:

It seems that BDR translates the xmin column of tables from the sending
node to the target node txid values.

So - instead of having a local FIFO table on each node, I could actually
still (like with single-master replication) have a global FIFO table of
invalidation events, being inserted into at the node actually making the
change.

When that invalidation event reaches a node the row gets a local xmin
value which can be compared to txid_snapshot_xmin() kept along every select.

So if I'm correct in observing that the xmin column gives me the a local
txid of the transaction inserting the invalidation event - even if it
was originally inserted on another node, then I think it'll work.

/Peter

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jan de Visser 2015-03-26 15:14:46 Re: Autovacuum query
Previous Message Steven Erickson 2015-03-26 12:41:15 Re: Autovacuum query