Re: pageinspect: add tuple_data_record()
От | James Coleman |
---|---|
Тема | Re: pageinspect: add tuple_data_record() |
Дата | |
Msg-id | CAAaqYe9AD8uiioe1i8k_133sAX_2f+4_5UmJ=YqRH92vYNwX7A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pageinspect: add tuple_data_record() (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: pageinspect: add tuple_data_record()
|
Список | pgsql-hackers |
There's plenty ways it can go horribly wrong. Let's start with something
simple:
BEGIN;
ALTER TABLE ... ADD COLUMN blarg INT;
INSERT ... (blag) VALUES (132467890);
ROLLBACK;
ALTER TABLE ... ADD COLUMN blarg TEXT;
If you now read the table with your function you'll see a dead row that
will re-interpret a int datum as a text datum. Which in all likelyhood
will crash the server.
That particular case gives this result:
ERROR: number of attributes in tuple header is greater than number of attributes in tuple descriptor
Some more extended monkeying with adding/dropping columns repeatedly
gave this result:
ERROR: unexpected end of tuple data
That error (unexpected end of tuple data) should (at least in the non-TOAST case)
prevent the bug of reading beyond the raw tuple data in memory, which would be
the easiest way I could imagine to cause a serious problem.
Is there a case that could crash outside of a non-primitive type that has unsafe
data reading code?
В списке pgsql-hackers по дате отправления: