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