From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
---|---|
To: | "Raji Sridar (raji)" <raji(at)cisco(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Concurrency issue under very heay loads |
Date: | 2009-07-16 21:03:21 |
Message-ID: | alpine.GSO.2.01.0907161655290.21429@westnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-performance |
On Wed, 15 Jul 2009, Raji Sridar (raji) wrote:
> 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.
The only clean way to generate sequence numbers without needing to worry
about duplicates is using nextval:
http://www.postgresql.org/docs/current/static/functions-sequence.html
If you're trying to duplicate that logic in your own code, there's
probably a subtle race condition in your implementation that is causing
the bug.
If you had two calls to nextval from different clients get the same value
returned, that might be a PostgreSQL bug. Given how much that code gets
tested, the more likely case is that there's something to tweak in your
application instead. I would advise starting with the presumption it's an
issue in your app rather than on the server side of things.
P.S. Posting the same question to two lists here is frowned upon;
pgsql-general is the right one for a question like this.
--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2009-07-16 21:11:17 | Re: Areca 1680 and RHEL/Centos 5.3 issue |
Previous Message | Relyea, Mike | 2009-07-16 20:24:44 | Re: Error in insert statement |
From | Date | Subject | |
---|---|---|---|
Next Message | William Scott Jordan | 2009-07-16 21:11:48 | Re: [PERFORM] Incr/Decr Integer |
Previous Message | Greg Stark | 2009-07-16 21:01:42 | Re: cluster index on a table |