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. > 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. Regards. Hiroshi Inoue

Reply via email to