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