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: | 24515.1151682922@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:
> 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);
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
From | Date | Subject | |
---|---|---|---|
Next Message | Brad Nicholson | 2006-06-30 16:03:07 | Re: Index corruption |
Previous Message | Jan Wieck | 2006-06-30 15:33:41 | Re: Index corruption |