Horton

Re: Range Types - typo + NULL string constructor

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

View thread
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, Alexander Korotkov <aekorotkov@gmail.com>, pgsql-hackers@postgresql.org
Date: 2011-10-26T15:52:28Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Replace the "New Linear" GiST split algorithm for boxes and points with a

On 26.10.2011 18:42, Robert Haas wrote:
> On Tue, Oct 25, 2011 at 12:37 PM, Jeff Davis<pgsql@j-davis.com>  wrote:
>> Aren't there a few other cases like this floating around the code? I
>> know the single-xid cache is potentially vulnerable to xid wraparound
>> for the same reason.
>
> I believe that we're in trouble with XIDs as soon as you have two
> active XIDs that are separated by a billion, ...

That's not what Jeff is referring to here, though (correct me if I'm 
wrong). He's talking about the one-item cache in 
TransactionIdLogFetch(). You don't need need long-running transactions 
for that to get confused. Specifically, this could happen:

1. In session A: BEGIN; SELECT * FROM foo WHERE id = 1; COMMIT;
    The row has xmin = 123456, and it is cached as committed in the 
one-item cache by TransactionLogFetch.
2. A lot of time passes. Everything is frozen, and XID wrap-around 
happens. (Session A is idle but not in a transaction, so it doesn't 
inhibit freezing.)
3. In session B: BEGIN: INSERT INTO foo (id) VALUES (2); ROLLBACK;
    By coincidence, this transaction was assigned XID 123456.
4. In session A: SELECT * FROM foo WHERE id = 2;
    The one-item cache still says that 123456 committed, so we return 
the tuple inserted by the aborted transaction. Oops.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com