Jeff Ross <jross@wykids.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