Hi,
Traditionally it hadn't made much sense to fire a trigger on a receiving
replica node (slave) - for many reasons, including it being read-only.
But with BDRs multi parter, partial replication and the possibility that
some tables are either actually or logically local to a single node,
th
On 2015-03-25 12:32, Craig Ringer wrote:
On 25 March 2015 at 19:15, Peter Mogensen wrote:
Say ... I have a table in a BDR replicated database with an "ON UPDATE"
trigger. - and that trigger wants to locally find out the local
txid_snapshot_xmin() when a change was applied to the
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
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
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 wa
Hi,
I would really like to be able to externally to Postgres at some point
in time later, be able to compare the txid of 2 queries.
Namely:
The INSERT transaction for a certain row in a table, and
The SELECT transaction reading some other data.
With the one caveat that this has to work with
On 2015-05-12 06:06, Craig Ringer wrote:
On 11 May 2015 at 21:10, Peter Mogensen wrote:
So ... I can easily get the current txid of the SELECT transaction by
calling txid_current().
Note that by doing so, you force txid allocation for a read-only query that
might otherwise not need one
On 2015-05-12 06:06, Craig Ringer wrote:
On 11 May 2015 at 21:10, Peter Mogensen wrote:
So ... I can easily get the current txid of the SELECT transaction by
calling txid_current().
Note that by doing so, you force txid allocation for a read-only query that
might otherwise not need one
l.org/wiki/BDR_Global_Sequences#How_global_sequences_are_managed_internally
But I can't find anything in the source remotely resembling an algorithm
like PAXOS or RAFT.
kind regards,
Peter Mogensen
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to yo
Hi,
I have an application where I would really like to be able to look at en
SQL query and answer the question:
"Is this query capable of returning more than 1 row?"
So basically, queries are divided into 2 categories. Those that look up
a single row (if it exists) and those who return a (po
On 2014-03-12 09:28, Albe Laurenz wrote:
Peter Mogensen wrote:
I have an application where I would really like to be able to look at en
SQL query and answer the question:
"Is this query capable of returning more than 1 row?"
Can I conclude that when plan_rows is 1 then there wil
11 matches
Mail list logo
