Re: regarding threads and transactions - problem 2 - Mailing list pgsql-general

From Martijn van Oosterhout
Subject Re: regarding threads and transactions - problem 2
Date
Msg-id 20050826081035.GB4848@svana.org
Whole thread Raw
In response to regarding threads and transactions - problem 2  ("Surabhi Ahuja " <surabhi.ahuja@iiitb.ac.in>)
List pgsql-general
On Fri, Aug 26, 2005 at 01:28:51PM +0530, Surabhi Ahuja  wrote:
> Dear All,
>
> This is in reference to a problem which I had put up sometime back.
> Please take some time to study it
>
> The piece of code that i am trying to execute is attached (itsa cpp file)
> The stored procedure (that the program calls) insert_patient is as follows:

Firstly, this has nothing to do with threads. Any programs executing
this in parallel would have the same problem.

> Please check the block in red. Why is it happening? insnt the call to the stored procedure considered one atomic
operation?
> Please tell me what is going wrong?
>
> Cant I avoid such red blocks? and get messages like the ones obained from the other threads
> I can impose locks but would not that lower down the performance?
> Please suggest other solutions

Well, you guarentee atomicity by using locks. And yes, locks do
decrease performance overall. Since you don't take any locks the
procedure can execute in parallel with anything else.

Your options are:
1. Lock the table in the procedure
2. Change to using a system that doesn't require such a strange update
procedure.
3. Trap the error and retry.

Option 2 would be the best, though option 3 would be faster than
option 1.

Hope this helps,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Attachment

pgsql-general by date:

Previous
From: "Surabhi Ahuja "
Date:
Subject: regarding threads and transactions - problem 2
Next
From: Richard Huxton
Date:
Subject: Re: Altering built-in functions cast