On Sunday 18 July 2010 19:20:25 Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On Sunday 18 July 2010 18:02:26 Simon Riggs wrote:
> >> Then I think the fix is to look at the xmin values on all of the tables
> >> used during planning and ensure that we only use constraint-based
> >> optimisations in a serializable transaction when our top xmin is later
> >> than the last DDL change (via its xmin).
> >
> > Why not just use a the normal snapshot at that point?
> There isn't a "normal snapshot" that the planner should be relying on.
> It doesn't know what snap the resulting plan will be used with.
Ok, I will write more stupid stuff in the next paragraph. Feel free to ignore.
What I meant was to use
* the transactions snapshot if we are in a transaction while planning
* SnapshotNow otherwise (not sure if thats a situation really existing - I yet
have no idea how such utitlity statements are handled snapshot-wise)
The errors I described shouldn't matter for an already existing plan. Also the
problem with a stale plan is already existing (only slightly aggravated due to
the change) and should be handled via plan invalidation. Right?
Phantasizing:
If you continued with that you even could allow read only access to tables
during ALTER TABLE et al. if the actual unlinking of the old filerelnode would
get moved to the checkpoint or similar...
> I'm unconvinced that this is a problem worth worrying about, but if it
> is then Simon's probably got the right idea: check the xmin of a
> pg_constraint row before depending on it for planning. Compare the
> handling of indexes made with CREATE INDEX CONCURRENTLY.
I am happy enough to write a docpatch for those issues and leave it there.
Andres
