From: | Oliver Elphick <olly(at)lfix(dot)co(dot)uk> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PITR - recovery to a particular transaction |
Date: | 2004-08-04 19:05:05 |
Message-ID: | 1091646305.31602.3099.camel@linda |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2004-08-04 at 19:16, Tom Lane wrote:
> Oliver Elphick <olly(at)lfix(dot)co(dot)uk> writes:
> > How about adding a logging option to put the transaction id on the log
> > for every statement that modifies the database? Would that be a small
> > enough change to be allowed into 8.0?
>
> I think we could get away with adding transaction ID as one of the
> available %-items in log_line_prefix. I'm not sure how useful this
> really is though --- timestamps are probably more useful overall to
> have in your log.
Why not both?
You seem to be suggesting that using the id is less useful than the
time, but surely it's going to be easier to say "this disaster happened
in transaction 123 so lets do a PITR up to 122" than to say "this
happened at time x so do PITR up to x - 1 second"; the latter might miss
several tranactions. Have I got the concepts wrong here?
> The direction I was expecting we'd head in is to
> provide WAL logfile examination tools.
But that's not going to happen for 8.0, so any means of getting the
transaction id is better than none.
--
Oliver Elphick olly(at)lfix(dot)co(dot)uk
Isle of Wight http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA
========================================
"And not only so, but we glory in tribulations also;
knowing that tribulation worketh patience; And
patience, experience; and experience, hope."
Romans 5:3,4
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2004-08-04 19:15:29 | Re: PITR - recovery to a particular transaction |
Previous Message | Kris Jurka | 2004-08-04 18:47:22 | Re: postgres and Jdbc 2.0 |