Jim C. Nasby wrote:
> > > I don't think it should (which implies that EXCLUSIVE is a bad name).
> >
> > Agreed, EXCLUSIVE was used to mean an _exclusive_ writer. The new words
> > I proposed were PRESERVE or STABLE.
>
> This seems to seriously limit the usefulness, though. You'll only want
> to use EXCLUSIVE/PRESERVE/STABLE when you've got a specific set of DML
> to do, that you know you can recover from. But if at the same time some
> other part of the system could be doing what it thinks will be ACID DML
> to that same table, you're now in trouble.
>
> At a minimum that would need to be clearly spelled out in the docs. I
> think it also makes a very strong use-case for exposing table-level
> shared locks as well, since that would at least allow other backends to
> continue reading from the table.
We would be creating a new lock type for this.
> Idealistically, if EXCLUSIVE/PRESERVE/STABLE does it's thing by only
> appending new pages, it would be nice if other backends could continue
> performing updates at the same time, assuming there's free space
> available elsewhere within the table (and that you'd be able to recover
> those logged changes regardless of the non-logged operations). But
> that's a pretty lofty goal...
"Idealistically", yep. It would be great if we could put a helmet on
and the computer would read your mind. :-)
Basically meaning your idea of update while EXCLUSIVE/PRESERVE/STABLE is
happening is never going to be implemented because it is just too hard
to do, and too prone to error.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073