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

Re: Index corruption

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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:25:05
Message-ID: 1151684705.2842.3.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackers
Ühel kenal päeval, R, 2006-06-30 kell 12:05, kirjutas Jan Wieck:
> On 6/30/2006 11:55 AM, Tom Lane wrote:
> 
> > Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> >> On 6/30/2006 11:17 AM, Marko Kreen wrote:
> >>> If the xxid-s come from different DB-s, then there can still be problems.
> > 
> >> How so? They are allways part of a multi-key index having the 
> >> originating node ID first.
> > 
> > Really?
> > 
> > create table @NAMESPACE(at)(dot)sl_log_1 (
> > 	log_origin			int4,
> > 	log_xid				@NAMESPACE(at)(dot)xxid,
> > 	log_tableid			int4,
> > 	log_actionseq		int8,
> > 	log_cmdtype			char,
> > 	log_cmddata			text
> > );
> > create index sl_log_1_idx1 on @NAMESPACE(at)(dot)sl_log_1
> > 	(log_origin, log_xid @NAMESPACE(at)(dot)xxid_ops, log_actionseq);
> > 
> > create index sl_log_1_idx2 on @NAMESPACE(at)(dot)sl_log_1
> > 	(log_xid @NAMESPACE(at)(dot)xxid_ops);
> 
> You're right ... forgot about that one. And yes, there can be 
> transactions originating from multiple origins (masters) in the same 
> log. The thing is, the index is only there because in a single origin 
> situation (most installations are), the log_origin is allways the same. 
> The optimizer therefore sometimes didn't think using an index at all 
> would be good.
> 
> 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.

The problem was not only with returning too many rows from tuples, but
as much returning too few. In case when you return too few rows some
actions will just be left out from replication and thus will be missing
from slaves.

-- 
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com




In response to

pgsql-hackers by date

Next:From: markDate: 2006-06-30 16:39:52
Subject: Re: Fixed length datatypes. WAS [GENERAL] UUID's as
Previous:From: Tom LaneDate: 2006-06-30 16:22:33
Subject: Re: Index corruption

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