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

Tom Lane wrote:
>
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)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?
>

I like neither unexpected errors nor doing the wrong
thing by handling tuples which aren't guaranteed to
be up-to-date. After mark4update, the tuple is
guaranteed to be up-to-date and heap_update won't
fail even though some commands etc neglect to lock
the correspoding relation. Isn't it proper to guard
myself as much as possible ?

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