On Saturday 17 July 2010 01:53:24 Robert Haas wrote: > On Jul 16, 2010, at 6:01 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Andres Freund <and...@anarazel.de> writes: > >> 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 :-( > > > > But the planner, along with most of the rest of the backend, *does* use > > SnapshotNow when examining the system catalogs. > > > > I share your feeling of discomfort but so far I don't see a hole in > > Simon's argument. Neither do I.
> > Adding a constraint should never make a > > previously-correct plan incorrect. Removing one is a very different > > story, but he says he's not changing that case. (Disclaimer: I have > > not read the patch.) > > Perhaps we should start by deciding whether Andres' case is a bug in the > first place, and then we can argue about whether it's a join-removal bug, > a lock-weakening bug, or a preexisting bug. The case where its possible to produce such a case *after* having used/locked all participating relations is new I think. Being able to create invalid results by doing DDL in another connection on not-yet-used tables is at least as old as constraint exclusion. Its a bit easier to work around, but thats it. So I personally would not consider this patch as having a bug anymore (thinking helps...). Whether the general issue is a bug or a to-be-more-exhausitive-documented- gotcha I have no idea. I know two people having hit it in production - I dont think its a that common issue though. Starting with the fact that not that many people use serializable. Just to help me: The primary reasons for using SnapshotNow is speed and in some cases correctness (referential integrity). Right? Any other reasons? Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
