Re: Reliable and fast money transaction design

Поиск
Список
Период
Сортировка
От Ron Johnson
Тема Re: Reliable and fast money transaction design
Дата
Msg-id 46D57696.5090307@cox.net
обсуждение исходный текст
Ответ на Re: Reliable and fast money transaction design  (cluster <skrald@amossen.dk>)
Ответы Re: Reliable and fast money transaction design  (Decibel! <decibel@decibel.org>)
Список pgsql-general
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/29/07 07:27, cluster wrote:
> OK, thanks. But what with the second question in which the UPDATE is
> based on a SELECT max(...) statement on another table? How can I ensure
> that no other process inserts a row between my SELECT max() and UPDATE -
> making my SELECT max() invalid?
>
> A table lock could be an option but I am only interested in blocking for
> row insertions for this particular account_id. Insertions for other
> account_ids will not make the SELECT max() invalid and should therefore
> be allowed.

Well, concurrency and transactional consistency *allows* other
processes to update the table after you start your transaction.  You
just won't *see* their updates while you're inside of a transaction.

Of course, if you truly want exclusive access, you could LOCK the
table.  It's well explained in the documentation...

- --
Ron Johnson, Jr.
Jefferson LA  USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG1XaWS9HxQb37XmcRAi5hAKDff5j5KnqWdGKxHjCJuTwXxfPwjACfZuko
1Ic5Bq1tU3IlPP44VYyD74M=
=Sv0p
-----END PGP SIGNATURE-----

В списке pgsql-general по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Etc/% timezones
Следующее
От: Naz Gassiep
Дата:
Сообщение: Re: Etc/% timezones