Re: Concurrency issue under very heay loads - Mailing list pgsql-performance

From Scott Marlowe
Subject Re: Concurrency issue under very heay loads
Date
Msg-id dcc563d10907152311m62c61f73j5c696912458a5cc8@mail.gmail.com
Whole thread Raw
In response to Concurrency issue under very heay loads  ("Raji Sridar (raji)" <raji@cisco.com>)
Responses Re: Concurrency issue under very heay loads  (Craig Ringer <craig@postnewspapers.com.au>)
List pgsql-performance
On Wed, Jul 15, 2009 at 10:59 PM, Raji Sridar (raji)<raji@cisco.com> wrote:
> Hi,
>
> We use a typical counter within a transaction to generate order sequence
> number and update the next sequence number. This is a simple next counter -
> nothing fancy about it.  When multiple clients are concurrently accessing
> this table and updating it, under extermely heavy loads in the system
> (stress testing), we find that the same order number is being generated for
> multiple clients. Could this be a bug? Is there a workaround? Please let me
> know.

As others have said, a serial is a good idea, HOWEVER, if you can't
have gaps in sequences, or each customer needs their own sequence,
then you get to lock the rows / table / etc that you're mucking with
to make sure you don't issue the same id number twice.  It's easy to
test your code by hand by running pieces of it in two different psql
sessions in such a way as to induce the race condition (or not if
you've got it right).

pgsql-performance by date:

Previous
From: "ramasubramanian"
Date:
Subject: Re: Concurrency issue under very heay loads
Next
From: Marc Cousin
Date:
Subject: Re: Very big insert/join performance problem (bacula)