Search Postgresql Archives

Re: [PERFORM] Concurrency issue under very heay loads

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux