Re: Concurrency issue under very heay loads

Поиск
Список
Период
Сортировка
Искать
От
Haszlakiewicz, Eric
Тема
Re: Concurrency issue under very heay loads
Дата
Msg-id
9D29FD18CBD74A478CBA86E6EF6DBAD403E27B73@CHI4EVS04.corp.transunion.com
Ответ на
Список
Дерево обсуждения
Concurrency issue under very heay loads "Raji Sridar (raji)" <raji@cisco.com>
Re: Concurrency issue under very heay loads "Haszlakiewicz, Eric" <EHASZLA@transunion.com>
Re: Concurrency issue under very heay loads "Albe Laurenz" <laurenz.albe@wien.gv.at>
Re: Concurrency issue under very heay loads Scott Marlowe <scott.marlowe@gmail.com>
Re: Concurrency issue under very heay loads Craig Ringer <craig@postnewspapers.com.au>
Re: [GENERAL] Concurrency issue under very heay loads Greenhorn <user.postgresql@gmail.com>
>-----Original Message-----
>From: pgsql-performance-owner@postgresql.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
В списке pgsql-performance по дате отправления
От: Kevin Grittner
Дата:
Сообщение: Re: Calling conventions
От: Krade
Дата:
FAQ