From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Why is LockClassinfoForUpdate()'s mark4update a good idea? |
Date: | 2001-01-16 02:32:20 |
Message-ID: | 29731.979612340@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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. What I want is a consistently applied coding
rule that protects all commands; and the simpler that coding rule is,
the more likely it is to be consistently applied. I do not think that
adding mark4update improves matters when seen in this light. The code
to do it is bulky and error-prone, and I have no confidence that it will
be done right everywhere.
In fact, at the moment I'm not convinced that it's done right anywhere.
The uses of mark4update for system-catalog updates are all demonstrably
broken right now, and the ones in the executor make use of a hugely
complex and probably buggy qualification re-evaluation mechanism. What
is the equivalent of qual re-evaluation for a system catalog tuple,
anyway?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2001-01-16 02:34:45 | Re: subselect bug? |
Previous Message | Hiroshi Inoue | 2001-01-16 02:19:33 | Re: Why is LockClassinfoForUpdate()'s mark4update a good idea? |