From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Why is LockClassinfoForUpdate()'s mark4update a good idea? |
Date: | 2001-01-16 03:13:25 |
Message-ID: | 3A63BC55.28B5D7A3@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > 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 ?
>
> If one piece of the system "guards itself" and others do not, what have
> you gained? Not much.
??? The system guarding itself won't gain bad result at least.
If one piece of system "guards others" and others do not, both
may gain bad results. Locking a class info by locking the
corrsponding relation is such a mechanism.
However I don't think we could introduce this mechanism to all
system catalogs. I implemented LockClassinfoForUpdate() by the
following reason.
1) pg_class is the most significant relation.
2) LockClassinfoForUpdate() adds few new conflicts
by locking the pg_class tuple because locking the
corresponding relation locks the pg_class entity
implicitly unless some stuff neglects to lock
corresponding relation.
Regards.
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 2001-01-16 04:54:25 | Re: MS Access vs IS NULL (was Re: [BUGS] Bug in SQL functions that use a NULL parameter directly) |
Previous Message | Lamar Owen | 2001-01-16 02:50:01 | 7.1beta3-2 RPMset uploading. |