Jeff Ross <jross@xxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
