From: | Marko Kreen <markokr(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: preserving forensic information when we freeze |
Date: | 2013-07-03 18:54:37 |
Message-ID: | CACMqXCJ0OLDV6bfSj+QNrm2yZUaxYuXNzben5scWydLwX4C2Tg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 3, 2013 at 8:07 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2013-07-02 16:29:56 -0400, Robert Haas wrote:
>> There's no possibility of getting confused here; if X is still around
>> at all, it's xmax is of the same generation as Y's xmin. Otherwise,
>> we've had an undetected XID wraparound.
>
> Another issue I thought about is what we will return for SELECT xmin
> FROM blarg; Some people use that in their applications (IIRC
> skytools/pqg/londiste does so) and they might get confused if we
> suddently return xids from the future. On the other hand, not returning
> the original xid would be a shame as well...
Skytools/pqg/londiste use only txid_* APIs, they don't look at
4-byte xids on table rows.
--
marko
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2013-07-03 18:56:55 | Re: refresh materialized view concurrently |
Previous Message | Josh Berkus | 2013-07-03 18:50:18 | Re: New regression test time |