Re: Multiple table entries?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Ross <jross(at)wykids(dot)org>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Multiple table entries?
Date: 2009-08-24 01:54:50
Message-ID: 15556.1251078890@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Jeff Ross <jross(at)wykids(dot)org> writes:
> Tom Lane wrote:
>> Well, it's a pretty bad bug but as far as I can see a simple "VACUUM
>> table" command should fix it up --- would you confirm?

> Hah! It did indeed clear it up!

[ thinks... ] Actually, that only proves that the PD_ALL_VISIBLE fixup
logic in vacuumlazy.c does what it's supposed to do; it doesn't in
itself show anything about how the flag got to be wrong. The path that
I'm seeing is enabled by the bogus coding that messes with the flag
after having done XLogInsert --- that's forbidden by our coding rules,
and the reason is that if XLogInsert chooses to log the entire page then
the replay routine will assume that all the required changes got applied
already. It's fairly easy to demonstrate the problem:

create table foo (f1 int, f2 int);
insert into foo values (1,2);
insert into foo values (3,4);
select ctid,xmin,xmax,* from foo;
vacuum foo;
vacuum foo;
checkpoint;
update foo set f2 = f2 + 1;
select ctid,xmin,xmax,* from foo;
-- now cause a crash, eg kill -9 on this backend

After recovery, there'll be two visible copies of the two rows.

However, this theory requires that you had a backend crash, and
you averred upthread that you hadn't ...

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Craig Ringer 2009-08-24 01:59:36 Re: libpq performance
Previous Message Jeff Ross 2009-08-24 01:24:59 Re: Multiple table entries?