Re: table as log (multiple writers and readers)

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

In response to

Responses

Browse pgsql-general by date

  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?