Re: [PERFORM] Concurrency issue under very heay loads

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: "Raji Sridar (raji)" <raji(at)cisco(dot)com>
Cc: pgsql-general(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Concurrency issue under very heay loads
Date: 2009-07-16 06:11:20
Message-ID: dcc563d10907152311m62c61f73j5c696912458a5cc8@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

On Wed, Jul 15, 2009 at 10:59 PM, Raji Sridar (raji)<raji(at)cisco(dot)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).

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ms swati chande 2009-07-16 07:02:53 Using the GEQO
Previous Message Steve Choi 2009-07-16 06:03:09 Re: How to DB export XML File in PostgreSQL?

Browse pgsql-performance by date

  From Date Subject
Next Message Marc Cousin 2009-07-16 07:41:05 Re: Very big insert/join performance problem (bacula)
Previous Message John R Pierce 2009-07-16 05:34:58 Re: Concurrency issue under very heay loads