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
