On 2018-10-17 17:02:20 -0400, James Coleman wrote:
> > 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
I don't see why you'd get that error, if you re-add a column (with a
different type), as I did above? Obviously the "replacement" column
addition would need to be committed.
> 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.
You don't need to read beyond the end of the data. You just need to do
something like reinterpret types, where the original type looks enough
like a toast header (e.g.) to cause problems.
> Is there a case that could crash outside of a non-primitive type that has
> unsafe data reading code?
Just about anything that's not a fixed length type would be unsafe.
Greetings,
Andres Freund
