On Friday 16 July 2010 22:24:32 Simon Riggs wrote: > On Fri, 2010-07-16 at 21:38 +0200, Andres Freund wrote: > > boom > > Your test case would still occur in the case where the first query had > not been executed against the same table. So the test case illustrates a > failing of join removal, not of this patch. Well, yes. Thats a well known (and documented) issue of pg's serialized transactions - which you can protect against quite easily (see the trunctate docs for example). The difference is that I know of no sensible way you sensibly could protect against such issues with the patch applied while its easy before(LOCK TABLE ... IN SHARE MODE for all used tables). I know of several sites which have *long* running serialized transactions open for analysis and I know there have been other cases of it.
Sure its not that bad, but at least it needs to get documented imho. Likely others should chime in here ;-) 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 :-( Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
