Jim C. Nasby wrote: > > 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.
Right, the DML will be single-threaded and fsync of all dirty pages will happen before commit of each transaction. > 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. :) Actually, it does hurt because it generates discussion volume for no purpose. -- 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 5: don't forget to increase your free space map settings