Re: Good name for new lock type for VACUUM?

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?