Why does LockClassinfoForUpdate() insist on doing heap_mark4update?
As far as I can see, this accomplishes nothing except to break
concurrent index builds.  If I do 

        create index tenk1_s1 on tenk1(stringu1);
        create index tenk1_s2 on tenk1(stringu2);

in two psqls at approximately the same time, the second one fails with

        ERROR:  LockStatsForUpdate couldn't lock relid 274157

which is entirely unnecessary.

I don't believe that the similar code in AlterTableDropColumn()
and AlterTableCreateToastTable() is a good idea either.  We do not
depend on "SELECT FOR UPDATE" on pg_class tuples for interlocking
changes to relations; we use exclusive locks on the relations themselves
for that.  mark4update is unnecessary in this context.

Comments?

                        regards, tom lane

Reply via email to