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