HeapTuple header changes cause core dumps in CVS tip

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Manfred Koizar <mkoi-pg(at)aon(dot)at>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: HeapTuple header changes cause core dumps in CVS tip
Date: 2002-07-15 20:46:44
Message-ID: 23412.1026766004@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-07-15 21:31:00 utils C files
Previous Message Marc Lavergne 2002-07-15 18:14:59 Re: COPY x FROM STDIN escape handlers