Re: [PERFORM] Concurrency issue under very heay loads - Mailing list pgsql-general

From Allan Kamau
Subject Re: [PERFORM] Concurrency issue under very heay loads
Date
Msg-id ab1ea6540907160244x15fd624bv93b2f6bf25476a16@mail.gmail.com
Whole thread Raw
In response to Re: [PERFORM] Concurrency issue under very heay loads  ("Albe Laurenz" <laurenz.albe@wien.gv.at>)
List pgsql-general
May be a simple way would be to use a "SEQUENCE" database object. And
call nextval('your_sequence') to obtain the next unique value (of type
bigint).
According to PG docs
"http://www.postgresql.org/docs/8.4/interactive/functions-sequence.html",
the sequence object has functions that "provide simple, multiuser-safe
methods for obtaining successive sequence values from sequence
objects. "

You may either provide this function as a default to the field in
which you'd like the unique values to go to.
OR
If you'd like to make use of this value before data is inserted to the
table simply call SELECT nextval('your_sequence') to obtain the next
unique bigint value which you may insert into the appropriate field in
your table and still the the value for later use maybe to populate a
child table.

Allan.

On Thu, Jul 16, 2009 at 11:15 AM, Albe Laurenz<laurenz.albe@wien.gv.at> wrote:
> Raji Sridar 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, 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.
>
> Please show us your code!
>
> Yours,
> Laurenz Albe
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

pgsql-general by date:

Previous
From: Rafael Martinez
Date:
Subject: Autovacuum and pg_stat_reset()
Next
From: Arndt Lehmann
Date:
Subject: Re: best practice transitioning from one datatype to another