| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
| Cc: | Marko Kreen <markokr(at)gmail(dot)com>, Marc Munro <marc(at)bloodnok(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Index corruption |
| Date: | 2006-06-30 16:22:33 |
| Message-ID: | 24778.1151684553@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jan Wieck <JanWieck(at)Yahoo(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2006-06-30 16:25:05 | Re: Index corruption |
| Previous Message | Brad Nicholson | 2006-06-30 16:18:06 | Re: Index corruption |