Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock

On Fri, 2010-07-16 at 20:45 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > Just to help me: The primary reasons for using SnapshotNow is speed and in
> > some cases correctness (referential integrity). Right? Any other reasons?
>
> Well, the main point for system catalog accesses is that you *must* have
> an up-to-date view of the table schemas. As an example, if someone just
> added an index to an existing table, it would not do for an INSERT to
> fail to update that index --- no matter whether it's from a serializable
> transaction or not. So the DDL-executing transaction must hold a lock
> that would block any operation that had better be able to see what it
> did, and once another transaction has acquired the lock that lets it go
> ahead with another operation, it had better see the results of the DDL
> transaction.
>
> However that argument mostly applies to what the executor does. A plan
> could still be usable despite having been made against a now-obsolete
> version of the table schema.
>
> In the case at hand, I think most constraint-adding situations would
> require at least ShareLock, because they had better block execution of
> INSERT/UPDATE/DELETE operations that could fail to honor the constraint
> if they didn't see it in the catalogs. But AFAICS, addition of a
> constraint need not block SELECT, and it need not invalidate existing
> plans.
>
> CREATE INDEX uses ShareLock because it's okay to run multiple CREATE
> INDEXes in parallel (thanks to some rather dodgy coding of the catalog
> updates). For other cases of constraint additions, it might not be
> practical to run two constraint additions in parallel. In that case we
> could use ShareRowExclusive instead, which is self-exclusive but is not
> any stronger than Share from the perspective of DML commands. Since
> it's not, I'm unconvinced that it's worth taking any great pains to try
> to make constraint additions run in parallel.

The patch follows all of the above exactly.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services