On Tue, Jan 03, 2006 at 04:20:47PM -0500, Bruce Momjian wrote:
> 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.
Sorry if I've just missed this in the thread, but what would the new
lock type do? My impression is that as it stands you can either do:
BEGIN;
ALTER TABLE EXCLUSIVE;
...
ALTER TABLE SHARE; --fsync
COMMIT;
Which would block all other access to the table as soon as the first
ALTER TABLE happens. Or you can:
ALTER TABLE EXCLUSIVE;
...
ALTER TABLE SHARE;
Which means that between the two ALTER TABLES every backend that does
DML on that table will not have that DML logged, but because there's no
exclusive lock that DML would be allowed to occur.
BTW, there might be some usecase for the second scenario, in which case
it would probably be better to tell the user to aquire a table-lock on
their own rather than do it automatically as part of the update...
> 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.
What I figured. Never hurts to ask though. :)
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461