Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock - Mailing list pgsql-hackers

From Andres Freund
Subject Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock
Date
Msg-id 201007182047.40099.andres@anarazel.de
Whole thread Raw
In response to Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle
Next
From: Joe Conway
Date:
Subject: Re: Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle