Re: Curious about exclusive table locks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Uwe C(dot) Schroeder" <uwe(at)oss4u(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Curious about exclusive table locks
Date: 2003-11-13 03:37:20
Message-ID: 18656.1068694640@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Uwe C. Schroeder" <uwe(at)oss4u(dot)com> writes:
> This works nice and throws no errors, however the line
> LOCK TABLE ib_counter IN ACCESS EXCLUSIVE MODE;
> seems to be ignored, since it's possible to create the same counter twice when
> the func is run twice at virtually the same time.

The lock is certainly being taken. The real problem is that the
snapshot has already been set (at the start of the interactive command
that invoked this function) and so your SELECT fetches a stale value.

You could probably make it work with

LOCK TABLE ib_counter IN ACCESS EXCLUSIVE MODE;
UPDATE ib_counter SET last_value = last_value + 1 WHERE name=countername;
SELECT INTO cprefix,counter,dlen prefix,last_value,display_length FROM
ib_counter WHERE name=countername;

The UPDATE will do the right thing (at least in READ COMMITTED mode) and
I believe the subsequent SELECT will be forced to see the UPDATE's
result.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2003-11-13 03:57:28 Re: plpgsql return setof integer?
Previous Message jini us 2003-11-13 03:07:54 Re: embedded postgresql