"Ilja Golshtein" <ilejn@xxxxxxxxx> 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
