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, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
