Re: limit number of concurrent callers to a stored proc?

From: Merlin Moncure
Subject: Re: limit number of concurrent callers to a stored proc?
Date: ,
Msg-id: 6EE64EF3AB31D5448D0007DD34EEB3417DD147@Herge.rcsinc.local
(view: Whole thread, Raw)
In response to: limit number of concurrent callers to a stored proc?  (Alan Stange)
List: pgsql-performance

Tree view

limit number of concurrent callers to a stored proc?  (Alan Stange, )
 Re: limit number of concurrent callers to a stored proc?  (Gavin Sherry, )
 Re: limit number of concurrent callers to a stored proc?  (Christopher Kings-Lynne, )
 Re: limit number of concurrent callers to a stored  (Ron, )
 Re: limit number of concurrent callers to a stored proc?  ("Merlin Moncure", )

Christopher
> You could use a 1 column/1 row table perhaps.  Use some sort of
locking
> mechanism.
>
> Also, check out contrib/userlock

userlock is definitely the way to go for this type of problem.

The are really the only way to provide locking facilities that live
outside transactions.

You are provided with 48 bits of lock space in the form of offset/block
in 32 bit field and a 16 bit field.  The 16 bit field could be the pid
of the locker and the 32 bit field the oid of the function.

Unfortunately, userlocks are not really easy to query via the pg_locks()
view.  However this has been addressed for 8.1.  In 8.1, it will be
trivial to create a function which checked the number of lockers on the
function oid and acquire a lock if less than a certain amount.

Merlin


pgsql-performance by date:

From: David Hodgkinson
Date:
Subject: Re: FW: Tx forecast improving harware capabilities.
From: Stéphane COEZ
Date:
Subject: Re: Performance pb vs SQLServer.