Hi,
On 2020-03-09 17:47:23 +0200, Kouber Saparev wrote:
> На пт, 6.03.2020 г. в 21:00 Andres Freund <andres@anarazel.de> написа:
> > On 2020-02-27 10:52:36 -0500, Tom Lane wrote:
> > > FWIW, I can't immediately think of a reason this would cause a problem,
> > > at least not on 9.4 and up which use MVCC catalog scans. If you're
> > > really still on 9.3 then it's notably more risky. In any case, I've
> > > not had any caffeine yet today, so this doesn't count for much.
> >
> > It likely could cause some problems if somebody concurrently executed
> > DDL affecting the same table. At least some "concurrently updated"
> > errors, and perhaps some worse ones. I'd at least add an explicit LOCK
> > TABLE on the underlying table that prevents concurrent catalog
> > modifications.
> >
>
> I am trying to escape the Access Exclusive lock over the table indeed,
> otherwise I would use the ALTER statement instead anyway, which makes a
> lock implicitly. Thanks for the responses.
You'd not have to take an ACCESS EXCLUSIVE. A lower level would
suffice, e.g. SHARE UPDATE EXCLUSIVE, which still allows data changes.
> There is nobody else doing DDLs except me - Mr. DBA, so I guess I am
> safe on this side. ;)
If autovacuum triggered a vacuum/analyze it'd would e.g. also try to
update pg_class.
Greetings,
Andres Freund
