Re: dataset lock - Mailing list pgsql-general

From Albe Laurenz
Subject Re: dataset lock
Date
Msg-id A737B7A37273E048B164557ADEF4A58B057E79B1@ntex2010a.host.magwien.gv.at
Whole thread Raw
In response to Re: dataset lock  (Philipp Kraus <philipp.kraus@flashpixx.de>)
List pgsql-general
Philipp Kraus wrote:
> My PG database is connected to differend cluster nodes (MPI). Each
> programm / process on each node are independed and run the SQL
> select * from table where status = waiting
> after that I update the row with the update statement (set status = working)
>
> so in this case one process can run the select, than comes another
> process and runs also the select, but both processes get an equal row.
> But this does not allowed. The second process need not see the row,
> which is taken by the first process. So can I suppress, that a select
> call
> sees a row, which is locked by a transaction? So I would like to do
> this with a store procedure, that runs the select and the update and
> after that
> it returns the PK of the selected dataset. If two (or more) processes
> run the SP at the same time, but the update can create an error, so the
> stored
> procedure is stopped and must called again.
> I need a solution, that a row, which is taken by one process not shown
> by all other processes

Do you want to implement something like a queue?

I can think of two techniques:

1) Locking
----------
In a transaction, you get a few rows for processing by
SELECT * FROM table WHERE status = waiting
   ORDER BY id LIMIT 5 FOR UPDATE;
("id" is the primary key here).
Then you process and update the rows and commit.

This will cause concurrent SELECT FOR UPDATE operations
to block until the transaction is committed, effectively
serializing the processing.

2) Set a marker
---------------
You get a few rows by
UPDATE table SET status = processing WHERE id IN
   (SELECT id FROM table WHERE status = waiting
       ORDER BY id LIMIT 5) RETURNING *;
Then process and update the rows.

This won't block concurrent processes for the whole
time it takes to process the rows, so it's probably
closer to what you want.

Yours,
Laurenz Albe


pgsql-general by date:

Previous
From: John R Pierce
Date:
Subject: Re: How to build my own 9.2.4 installer package for IBM Power System ppc64
Next
From: François Beausoleil
Date:
Subject: Re: Most efficient way to insert without duplicates