> ALTER TABLE ADD CONSTRAINT would certainly have taken > AccessExclusiveLock on the "example" table, which should be sufficient > to prevent anything else from touching its pg_class row. The only > mechanism I can think of that might bypass that is a manual UPDATE on > pg_class, which would just manipulate the row as a row without concern > for associated relation-level locks. Any chance that somebody was > doing something like that?
No chance. Our infrastructure dont do that, and users dont just have the privileges to mess with pg_catalog. ср, 25 окт. 2023 г. в 21:06, Tom Lane <t...@sss.pgh.pa.us>: > Smolkin Grigory <smallk...@gmail.com> writes: > > We are running PG13.10 and recently we have encountered what appears to > be > > a bug due to some race condition between ALTER TABLE ... ADD CONSTRAINT > and > > some other catalog-writer, possibly ANALYZE. > > The problem is that after successfully creating index on relation (which > > previosly didnt have any indexes), its pg_class.relhasindex remains set > to > > "false", which is illegal, I think. > > Index was built using the following statement: > > ALTER TABLE "example" ADD constraint "example_pkey" PRIMARY KEY (id); > > ALTER TABLE ADD CONSTRAINT would certainly have taken > AccessExclusiveLock on the "example" table, which should be sufficient > to prevent anything else from touching its pg_class row. The only > mechanism I can think of that might bypass that is a manual UPDATE on > pg_class, which would just manipulate the row as a row without concern > for associated relation-level locks. Any chance that somebody was > doing something like that? > > regards, tom lane >
