Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock

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