On Fri, 2010-07-16 at 23:03 +0200, Andres Freund wrote: > Sure its not that bad, but at least it needs to get documented imho. > Likely others should chime in here ;-)
Don't understand you. This is a clear bug in join removal, test case attached, a minor rework of your original test case. > What could the join removal path (and similar places) *possibly* do > against such a case? Without stopping to use SnapshotNow I dont see > any way :-( The bug is caused by allowing join removal to work in serializable transactions. The fix for 9.0 is easy and clear: disallow join removal when planning a query as the second or subsequent query in a serializable transaction. A wider fix might be worth doing for 9.1, not sure. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services
CREATE TABLE testsnap(t int); CREATE TABLE testsnap2 (); INSERT INTO testsnap VALUES(1),(1); T1: BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; SELECT count(*) FROM testsnap2; -- serializable snapshot is frozen T2: DELETE FROM testsnap; ALTER TABLE testsnap ADD CONSTRAINT t unique(t); T1: SELECT count(*) FROM testsnap; SELECT t1.* FROM testsnap t1 LEFT JOIN testsnap t2 USING(t); explain analyze SELECT t1.* FROM testsnap t1 LEFT JOIN testsnap t2 USING(t);
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
