Re: Why is LockClassinfoForUpdate()'s mark4update a good idea?

Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> Tom Lane wrote:
>> Why does LockClassinfoForUpdate() insist on doing heap_mark4update?

> Because I want to guard the target pg_class tuple by myself.
> I don't think we could rely on the assumption that the lock on
> the corresponding relation is held. For example, AlterTableOwner()
> doesn't seem to open the corresponding relation.

Possibly AlterTableOwner is broken.  Not sure that it matters though,
because heap_update won't update a tuple anyway if another process
committed an update first.  That seems to me to be sufficient locking;
exactly what is the mark4update adding?

(BTW, I notice that a lot of heap_update calls don't bother to check
the result code, which is probably a bug ...)

>> 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

> This is my fault. The error could be avoided by retrying 
> to acquire the lock like "SELECT FOR UPDATE" does.

I have a more fundamental objection, which is that if you think that
this is necessary for index creation then it is logically necessary for
*all* types of updates to system catalog tuples.  I do not like that
answer, mainly because it will clutter the system considerably ---
to no purpose.  The relation-level locks are necessary anyway for schema
updates, and they are sufficient if consistently applied.  Pre-locking
the target tuple is *not* sufficient, and I don't think it helps anyway
if not consistently applied, which it certainly is not at the moment.
        regards, tom lane