Tom Lane wrote: >Awhile ago I said that I wanted to create a new flavor of table-level >lock for concurrent VACUUM to get on a table. RowExclusiveLock is >not the right thing because it is not self-exclusive, whereas we don't >want more than one VACUUM mangling a table at a time. But anything >higher locks out concurrent writers, which we don't want either. >So we need an intermediate lock type that will conflict with itself >as well as with ShareLock and above. (It must conflict with ShareLock >since we don't want new indexes being created during VACUUM either...) > *snip* > >BTW, I'm assuming that I should make the new lock type available >at the user level as a LOCK TABLE option. Any objections to that? > I think that type of lock would best be kept to the system level. *thinking out loud* If your goal is to have it used more often, then user level might provide more opportunities for testing. However, I can't really think of any situation where it would be beneficial to a user. The rest of the locks seem to take care of everything else. Is it going to timeout? If a connection is dropped by a user, will the lock release? ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly