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
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 |
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 |