HeapTuple header changes cause core dumps in CVS tip

Поиск
Список
Период
Сортировка
От Tom Lane
Тема HeapTuple header changes cause core dumps in CVS tip
Дата
Msg-id 23412.1026766004@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: HeapTuple header changes cause core dumps in CVS tip  (Manfred Koizar <mkoi-pg@aon.at>)
Список 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
whileprocessing 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Marc Lavergne
Дата:
Сообщение: COPY x FROM STDIN escape handler
Следующее
От: Bruce Momjian
Дата:
Сообщение: getopt_long search in configure