From: | Rod Taylor <rbt(at)rbt(dot)ca> |
---|---|
To: | the2(at)newsgroup2(dot)com |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: New to SQL; hopefully simple question |
Date: | 2003-04-23 17:40:08 |
Message-ID: | 1051119608.38778.28.camel@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Fri, 2003-04-18 at 18:58, foo2(at)on-spammers2(dot)com wrote:
> I have a situation where I want to keep a bunch of ordinals in a row
> of a table maintained by the database. From this table, I want to
> obtain a number, and increment it in the table. This is the general
> idea, abstracted to the key parts (and it works, as far as it goes:
>
> "select valueone from ordtable"
> VALUE = PQgetvalue(res,0,0)
> ...compute VALUE = VALUE + 1
> "update ordtable SET valueone = VALUE"
>
> ...as I said, this works. however, as far as I understand it, it's
> divisible and thus subject to multi-user fugue. What I need,
> conceptually, is:
>
> lock the table so anyone else waits for the unlock (not fails, waits)
> do the above
> unlock the table
>
> Can anyone point me in the right direction for this? I looked at lock,
> but it seems to only apply across one DB action. Yes? No?
No.. table locks will persist for the length of the transaction.
BEGIN;
LOCK TABLE ...;
SELECT ...
<computations>
UPDATE ...
COMMIT;
However, does your update really change the entire table? If you are
updating the same row as you selected (same WHERE clause in SELECT and
UPDATE statements) you can:
BEGIN;
SELECT ... WHERE ... FOR UPDATE OF ordtable;
<computations>
UPDATE ... WHERE ...;
COMMIT;
The above locks only the rows you intend to work with rather than the
entire table. This can allow work to happen on the unlocked
(non-selected) rows on the table.
--
Rod Taylor <rbt(at)rbt(dot)ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2003-04-23 17:48:38 | Re: Optomizing left outer joins |
Previous Message | Josh Berkus | 2003-04-23 17:21:38 | Re: Why is seq search preferred here by planner? |