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?
