Hi, On 2020-03-09 17:47:23 +0200, Kouber Saparev wrote: > На пт, 6.03.2020 г. в 21:00 Andres Freund <andres@xxxxxxxxxxx> написа: > > 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
