Skip site navigation (1) Skip section navigation (2)

Re: Index corruption

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 14:44:07
Message-ID: 44A538B7.4090505@Yahoo.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 6/30/2006 9:55 AM, Tom Lane wrote:
> "Marko Kreen" <markokr(at)gmail(dot)com> writes:
>> The sl_log_* tables are indexed on xid, where the relations between
>> values are not exactly stable.  When having high enough activity on
>> one node or having nodes with XIDs on different enough positions
>> funny things happen.
> 
> Yeah, that was one of the first things I thought about, but the range of
> XIDs involved in these test cases isn't large enough to involve a
> wraparound, and anyway it's now looking like the problem is loss of heap
> entries, not index corruption at all.
> 
> Slony's use of XID comparison semantics for indexes is definitely pretty
> scary though.  If I were them I'd find a way to get rid of it.  In
> theory, since the table is only supposed to contain "recent" XIDs,
> as long as you keep it vacuumed the index should never contain any
> inconsistently-comparable XIDs ... but in a big index, the boundary keys
> for upper-level index pages might hang around an awful long time ...

With the final implementation of log switching, the problem of xxid 
wraparound will be avoided entirely. Every now and then slony will 
switch from one to another log table and when the old one is drained and 
logically empty, it is truncated, which should reinitialize all indexes.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Responses

pgsql-hackers by date

Next:From: Marko KreenDate: 2006-06-30 15:17:26
Subject: Re: Index corruption
Previous:From: Tom LaneDate: 2006-06-30 14:04:38
Subject: Re: Index corruption

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group