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
|
Список | 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 по дате отправления: