Re: Help needed for reading postgres log : RE: [GENERAL] Concurrency issue under very heay loads

2009-07-20 Thread Alvaro Herrera
Raji Sridar (raji) wrote: > I would like some help in reading the postgres logs. > Here is a snippet of the log. > Auto commit seems to be set to false. > But still the logs shows "CommitTransactionCommand" in debug mode. > The same order number is given for multiple clients. > Please see "CommitTr

Re: [GENERAL] Concurrency issue under very heay loads

2009-07-20 Thread Raji Sridar (raji)
9-07-17 14:10:59 4736 970134 LOG: duration: 0.000 ms 2009-07-17 14:10:59 4736 970134 STATEMENT: UPDATE tableEntityID SET nextEntityID = $1 WHERE entityType = $2 2009-07-17 14:10:59 4736 970134 DEBUG: ProcessQuery 2009-07-17 14:10:59 4736 970134 STATEMENT: UPDATE tableEntityID SET nextEntityID = $1 WHERE entity

Help needed for reading postgres log : RE: [GENERAL] Concurrency issue under very heay loads

2009-07-20 Thread Raji Sridar (raji)
= $1 WHERE entityType = $2 2009-07-17 14:10:59 4736 970134 LOG: duration: 0.000 ms 2009-07-17 14:10:59 4736 970134 STATEMENT: UPDATE tableEntityID SET nextEntityID = $1 WHERE entityType = $2 2009-07-17 14:10:59 4736 970134 DEBUG: ProcessQuery 2009-07-17 14:10:59 4736 970134 STATEMENT: UPDATE tab

Re: [GENERAL] Concurrency issue under very heay loads

2009-07-17 Thread Raji Sridar (raji)
2-506. Thanks Raji -Original Message- From: Greg Smith [mailto:gsm...@gregsmith.com] Sent: Thursday, July 16, 2009 2:03 PM To: Raji Sridar (raji) Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] Concurrency issue under very heay loads On Wed, 15 Jul 2009, Raji Sridar (raji) wrote: &

Re: [GENERAL] Concurrency issue under very heay loads

2009-07-17 Thread Craig Ringer
On Wed, 2009-07-15 at 22:34 -0700, John R Pierce wrote: > sounds like you should be using a SERIAL (which is implemented as an > INTEGER or BIGINT field with an associated SEQUENCE), as these DO work > just fine under heavy concurrency without any gotchas. There is one gotcha, though we're all

Re: [GENERAL] Concurrency issue under very heay loads

2009-07-16 Thread Greg Smith
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 se

Re: [GENERAL] Concurrency issue under very heay loads

2009-07-16 Thread Bill Moran
"Raji Sridar (raji)" wrote: > > 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, unde

Re: [GENERAL] Concurrency issue under very heay loads

2009-07-15 Thread John R Pierce
Raji Sridar (raji) 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 exter

Re: [GENERAL] Concurrency issue under very heay loads

2009-07-15 Thread Greenhorn
2009/7/16 Raji Sridar (raji) : > 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, u

[GENERAL] Concurrency issue under very heay loads

2009-07-15 Thread Raji Sridar (raji)
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 syst