Re: table as log (multiple writers and readers)
| От | Craig Ringer |
|---|---|
| Тема | Re: table as log (multiple writers and readers) |
| Дата | |
| Msg-id | 48062AD5.8040504@postnewspapers.com.au обсуждение исходный текст |
| Ответ на | Re: table as log (multiple writers and readers) (brian <brian@zijn-digital.com>) |
| Ответы |
Re: table as log (multiple writers and readers)
Re: table as log (multiple writers and readers) |
| Список | pgsql-general |
brian wrote:
> Use a timestamp column also.
That's subject to the same issues, because a transaction's
current_timestamp() is determined at transaction start. So, in a
situation like this:
WRITER 1 WRITER 2 READER 1
--------------------------------------------
BEGIN
BEGIN
INSERT
INSERT
COMMIT
BEGIN
SELECT
COMMIT
then READER 1 will see the most recent timestamp as that inserted by
WRITER 2, but it won't see the row inserted by WRITER 1 with an earlier
timestamp.
I don't think it's even OK in the case of a single-statement INSERT
(where the transaction is implicit) and/or with the use of
clock_timestamp() ... though I'm less sure about that.
--
Craig Ringer
В списке pgsql-general по дате отправления: