From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Point in Time Recovery |
Date: | 2004-07-06 07:38:47 |
Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA40184D12D@m0114.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> - by time - but the time stamp on each xlog record only specifies to the
> second, which could easily be 10 or more commits (we hope....)
>
> Should we use a different datatype than time_t for the commit timestamp,
> one that offers more fine grained differentiation between checkpoints?
Imho seconds is really sufficient. If you know a more precise position
you will probably know it from backend log or an xlog sniffer. With those
you can easily use the TransactionId way.
> - when we stop, keep reading records until EOF, just don't apply them.
> When we write a checkpoint at end of recovery, the unapplied
> transactions are buried alive, never to return.
> - stop where we stop, then force zeros to EOF, so that no possible
> record remains of previous transactions.
> I'm tempted by the first plan, because it is more straightforward and
> stands much less chance of me introducing 50 wierd bugs just before
> close.
But what if you restore because after that PIT everything went haywire
including the log ? Did you mean to apply the remaining changes but not
commit those xids ? I think it is essential to only leave xlogs around
that allow a subsequent rollforward from the same old full backup.
Or is an instant new full backup required after restore ?
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Pflug | 2004-07-06 07:51:01 | Re: Bug with view definitions? |
Previous Message | Simon Riggs | 2004-07-06 07:05:06 | Re: Recovery Features |