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

[Hiroshi Inoue]

Tom Lane wrote: > > Hiroshi Inoue <[EMAIL PROTECTED]> 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