| From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
|---|---|
| To: | brian <brian(at)zijn-digital(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: table as log (multiple writers and readers) |
| Date: | 2008-04-16 16:35:33 |
| Message-ID: | 48062AD5.8040504@postnewspapers.com.au |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rodrigo Gonzalez | 2008-04-16 16:53:32 | Re: Master-master replication with PostgreSQL |
| Previous Message | brian | 2008-04-16 16:11:39 | Re: table as log (multiple writers and readers) |