From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Jan Wieck" <JanWieck(at)Yahoo(dot)com> |
Cc: | "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: Commit timestamp |
Date: | 2007-01-26 13:26:21 |
Message-ID: | 1169817982.3772.315.camel@silverbirch.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2007-01-25 at 18:16 -0500, Jan Wieck wrote:
> To provide this data, I would like to add another "log" directory,
> pg_tslog. The files in this directory will be similar to the clog, but
> contain arrays of timestamptz values. On commit, the current system time
> will be taken. As long as this time is lower or equal to the last taken
> time in this PostgreSQL instance, the value will be increased by one
> microsecond. The resulting time will be added to the commit WAL record
> and written into the pg_tslog file.
A transaction time table/log has other uses as well, so its fairly
interesting to have this.
> COMMIT [TRANSACTION] [WITH TIMESTAMP <timestamptz>];
>
> The extension is limited to superusers and will override the normally
> generated commit timestamp.
I don't think its acceptable to override the normal timestamp. That
could lead to non monotonic time values which could screw up PITR. My
view is that you still need PITR even when you are using replication,
because the former provides recoverability and the latter provides
availability.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2007-01-26 13:31:00 | Re: Proposal: Snapshot cloning |
Previous Message | Jan Wieck | 2007-01-26 13:21:40 | Re: Proposal: Commit timestamp |