Re: [PERFORM] Concurrency issue under very heay loads

From: "Haszlakiewicz, Eric" <EHASZLA(at)transunion(dot)com>
To: "Raji Sridar \(raji\)" <raji(at)cisco(dot)com>, <pgsql-general(at)postgresql(dot)org>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: [PERFORM] Concurrency issue under very heay loads
Date: 2009-07-17 19:13:26
Message-ID: 9D29FD18CBD74A478CBA86E6EF6DBAD403E27B73@CHI4EVS04.corp.transunion.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

>-----Original Message-----
>From: pgsql-performance-owner(at)postgresql(dot)org
>
>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.

Are you using "for update" in your select statements? Are you setting
an appropriate transaction isolation level?

A better way to do this is with a sequence instead. This is guaranteed
to give you a unique value:
select nextval('address_serial_num_seq');

eric

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Craig Ringer 2009-07-17 19:24:35 Re: memory leak occur when disconnect database
Previous Message Craig Ringer 2009-07-17 18:55:08 Re: Idle in transaction

Browse pgsql-performance by date

  From Date Subject
Next Message Krade 2009-07-18 22:07:56 Full text search with ORDER BY performance issue
Previous Message Kevin Grittner 2009-07-17 17:35:51 Re: Calling conventions