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

Re: Index corruption

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 15:55:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.


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);

sl_log_1_idx2 doesn't seem to have any such protection.  When I was
poking at Marc's example, though, it seemed that the numbers going
into the table were all *locally generated* XIDs, in fact the same
as the XID doing the insertions.  If this is only true on the master,
and slaves can be inserting XIDs coming from different masters,
then I think it will break.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Brad NicholsonDate: 2006-06-30 16:03:07
Subject: Re: Index corruption
Previous:From: Jan WieckDate: 2006-06-30 15:33:41
Subject: Re: Index corruption

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