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,
Pennsylvania19073
