From: | "Vance Maverick" <vmaverick(at)pgp(dot)com> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: table as log (multiple writers and readers) |
Date: | 2008-04-16 17:55:06 |
Message-ID: | 1208368506.23897.7.camel@vmaverick-linux3.pgp.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> wrote:
> brian wrote:
>
> > Use a timestamp column also.
>
> That's subject to the same issues.
[...]
> 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.
No, you're right. The problem is that the timestamp is chosen some time
before the commit succeeds. So if there are concurrent writers
committing at the same time, the order of commit is determined by a
race, one that takes place after the timestamp values are set.
Another approach would be to queue the log entries in a "staging" table,
so that a single process could move them into the log. This is fairly
heavyweight, but it would guarantee the consistent sequencing of the log
as seen by a reader (even if the order of entries in the log didn't
always reflect the true commit sequence in the staging table). I'm
hoping someone knows a cleverer trick.
Vance
From | Date | Subject | |
---|---|---|---|
Next Message | Ralph Smith | 2008-04-16 17:58:32 | Re: I need to ecrypt one column to an output file |
Previous Message | wasenbr | 2008-04-16 17:38:34 | How to retore a pg_dumpall dump? |