"Ilja Golshtein" <ilejn@yandex.ru> writes:
> I need table level locks for cooperative usage in my application.
> LOCK TABLE table_name in EXCLUSIVE MODE
> and
> LOCK TABLE table_name in SHARED MODE
> perfectly suit my needs.
The question is *why* you feel you need that, ie what are you using
these for? As was already mentioned upthread, it's usually better
to avoid explicit locking altogether, if you can.
> The only drawback - interference with VACUUM and other system processes
> with obvious performance/response time penalty.
I can hardly imagine an ordinary lock type that doesn't conflict with
anything at all ... ALTER/DROP TABLE being the obvious counterexamples.
If you don't want your "shared" lock to conflict with VACUUM then you
could use ACCESS SHARE instead of SHARE, and it would still block
EXCLUSIVE.
> Honestly I've already introduced such locks with syntax
> LOCK TABLE table_name in APPLICATION EXCLUSIVE MODE
> and
> LOCK TABLE table_name in APPLICATION SHARED MODE
> Does publishing of this patch make any sense?
It's quite unlikely to get accepted, considering that advisory locks
already seem to cover the territory. (8.2 has blocking versions of
those calls BTW.)
regards, tom lane