From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Peter Mogensen <apm(at)one(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Comparing txid and xmin (under BDR) |
Date: | 2015-05-12 04:06:34 |
Message-ID: | CAMsr+YFjmojJZfz7c_YmNbd8N7=XbrJXgPa0PwJ4DKjObNhcpQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 11 May 2015 at 21:10, Peter Mogensen <apm(at)one(dot)com> wrote:
> 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 BDR.
>
> 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, which increases your txid burn rate and
decreases time until you need to do wraparound-protection vacuuming.
>
> However, - I can't in general compare it to the xmin of the table row.
> BDR does ensure (it seems) that xmin is meaningfull within the local node
> xid context.
>
Or, rather, it doesn't do anything different to what PostgreSQL its self
does.
I'm still not at all convinced that your desire to use transaction IDs for
the cache invalidation stuff you're doing makes sense or will work sensibly
even in a single-node environment. It's certainly not going to when
comparing between nodes, especially in an async system.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Mogensen | 2015-05-12 05:19:07 | Re: Comparing txid and xmin (under BDR) |
Previous Message | Peter Eisentraut | 2015-05-11 19:58:56 | Re: RPM building tools and info missing? |