On Wed, Nov 4, 2015 at 9:15 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > I certainly understand there are cases that require care - like the > leakproof thing pointed out by Robert for example. I don't immediately see > why evaluation against dead rows would be a problem.
Well, one thing is that you might leak information about already-deleted rows, which could be a security vulnerability, or more mundanely cause a function to error out when there are no actually visible rows that could trigger such an error. It would be surprising if you could add a CHECK(b != 0) constraint to a table, query it for rows where a/b>1, and get a division by zero error. But I think it's even worse: I believe there can be dead rows in the heap whose tuple descriptor doesn't even match the current pg_attribute contents. Consider BEGIN; ALTER TABLE ... ADD COLUMN ... int8; INSERT ...; ROLLBACK; ALTER TABLE .. ADD COLUMN .. text; SELECT ... If the SELECT tries to decode one of the tuples added by the failed transaction considering the new column as text when the dead tuples in question had it as an int8, I suspect that you can crash the server. Nothing good will happen, anyway. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
