An example is:
regression=# create table foo (f1 text);
CREATE TABLE
regression=# insert into foo values ('zzzzzzzzzzzzz');
INSERT 148289 1
regression=# insert into foo select * from foo;
INSERT 148290 1
regression=# insert into foo select * from foo;
INSERT 0 2
regression=# insert into foo select * from foo;
INSERT 0 4
<< repeat enough times to have 1000 or so tuples in table >>
regression=# insert into foo values ('q');
INSERT 150337 1
regression=# delete from foo where f1 != 'q';
DELETE 2048
regression=# vacuum full foo;
VACUUM
regression=# update foo set f1 = 'qq';
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Backtracing shows that the assertion in HeapTupleHeaderSetCmax fails,
because it's not expecting to find the HEAP_MOVED bits set in its input.
(The above test is simply an easy way of forcing an update on a tuple
that has been moved by VACUUM FULL.)
I am not sure if this is a bug introduced by the patch, or if it's
exposed a previously lurking bug. It seems that the HEAP_MOVED bits
should be cleared before re-using cmax for something else, but I have
not dug through the old logic to see how it was done before. Or perhaps
we cannot really reduce the number of fields this far.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
