At 01:26 PM 11-01-2001 -0500, Tom Lane wrote:
>Lincoln Yeoh <[EMAIL PROTECTED]> writes:
>> GETLOCK "string" will lock on "string", the lock being only released at the
>> end of a transaction.
>However, the whole thing strikes me as more of an ugly kluge than a
>clean solution to the real problem.
At 09:20 AM 11-01-2001 -0800, Mikheev, Vadim wrote:
>> In contrast the current alternatives appear to be either LOCK
>> the entire table (preventing ALL inserts and selects),
>
>SHARE ROW EXCLUSIVE mode doesn't prevent selects...
Sorry, I meant all inserts and selects on the locked table. At lea
Tom Lane wrote:
> Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> > Has anyone any input to offer on adding an arbitrary locking feature?
>
> > Where
> > GETLOCK "string" will lock on "string", the lock being only released at the
> > end of a transaction.
>
> > Any comments, suggestions or tips would b
Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> Has anyone any input to offer on adding an arbitrary locking feature?
> Where
> GETLOCK "string" will lock on "string", the lock being only released at the
> end of a transaction.
> Any comments, suggestions or tips would be welcome. It looks like quite
On Thu, Jan 11, 2001 at 03:43:39PM +0800, Lincoln Yeoh wrote:
> Hi,
>
> Has anyone any input to offer on adding an arbitrary locking feature?
>
> Where
> GETLOCK "string" will lock on "string", the lock being only released at the
> end of a transaction.
>
> While the lock is held, other process
> In contrast the current alternatives appear to be either LOCK
> the entire table (preventing ALL inserts and selects),
SHARE ROW EXCLUSIVE mode doesn't prevent selects...
> or to create a UNIQUE constraint (forcing complete rollbacks
> and restarts in event of a collision :( ).
Hopefully, sa
