Re: Index corruption - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Index corruption
Date
Msg-id 24778.1151684553@sss.pgh.pa.us
Whole thread Raw
In response to Re: Index corruption  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
Jan Wieck <JanWieck@Yahoo.com> writes:
> You're right ... forgot about that one.

> However, transactions from different origins are NEVER selected together 
> and it wouldn't make sense to compare their xid's anyway. So the index 
> might return index tuples for rows from another origin, but the 
> following qualifications against the log_origin in the heap tuple will 
> filter them out.

No, that's not the point here.  The point here is that if the xids that
are simultaneously present in the index span more than a 2G-XID range,
btree *will fail* because it will be dealing with keys that do not obey
the transitive law.  You do have a problem --- it doesn't explain Marc's
troubles, but sl_log_1_idx2 is broken for multi master situations.  All
you need is masters with sufficiently different XID counters.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Brad Nicholson
Date:
Subject: Re: Index corruption
Next
From: Hannu Krosing
Date:
Subject: Re: Index corruption