On Wed, Apr 19, 2006 at 10:20:54AM +0200, Mario Splivalo wrote:
> This works perfectly, but sometimes the game has no codes, and I still
> need to know exactley who came first, who was second, and so on... So a
> locking table as Tom suggested is, I guess, a perfect solution for my
> situation...
On Tue, 2006-04-18 at 19:00 +0200, PFC wrote:
> Suppose you have a table codes :
> (
> game_id INT,
> codeTEXT,
> usedBOOL NOT NULL DEFAULT 'f',
> prize ...
> ...
> PRIMARY KEY (game_id, code)
> )
>
> Just UPDATE codes SET
On Tue, 2006-04-18 at 11:33 -0400, Tom Lane wrote:
> Mario Splivalo <[EMAIL PROTECTED]> writes:
> >> If there is concurrent locking,
> >> you're also running a big risk of deadlock because two processes might
> >> try to lock the same rows in different orders.
>
> > I think there is no risk of a d
Suppose you have a table codes :
(
game_idINT,
codeTEXT,
usedBOOL NOT NULL DEFAULT 'f',
prize...
...
PRIMARY KEY (game_id, code)
)
Just UPDATE codes SET used='t' WHERE used='f' AND game_id=... AND
code=...
Then check the rowcount : if
Suppose you have a table codes :
(
game_id INT,
codeTEXT,
usedBOOL NOT NULL DEFAULT 'f',
prize ...
...
PRIMARY KEY (game_id, code)
)
Just UPDATE codes SET used='t' WHERE used='f' AND game_id=... AND
code=.
Mario Splivalo <[EMAIL PROTECTED]> writes:
>> If there is concurrent locking,
>> you're also running a big risk of deadlock because two processes might
>> try to lock the same rows in different orders.
> I think there is no risk of a deadlock, since that particular function
> is called from the mi
Mario Splivalo <[EMAIL PROTECTED]> writes:
> For the purpose of the application I need to establish some form of
> serialization, therefore I use FOR UPDATE. The query, inside the
> function, is like this:
> pulitzer2=# explain analyze select id FROM messages JOIN
> ticketing_codes_played ON id =
