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
