Taking advantage of the freeze bubble allowed us... there are some last minute features to add.
Summarising earlier thoughts, with some detailed digging and design from myself in last few days - we're now in a position to add Point-in-Time Recovery, on top of whats been achieved. The target for the last record to recover to can be specified in 2 ways: - by transactionId - not that useful, unless you have a means of identifying what has happened from the log, then using that info to specify how to recover - coming later - not in next few days :( - 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? If we did, would that be portable? Suggestions welcome, because I know very little of the details of various *nix systems and win* on that topic. Only COMMIT and ABORT records have timestamps, allowing us to circumvent any discussion about partial transaction recovery and nested transactions. When we do recover, stopping at the timestamp is just half the battle. We need to leave the xlog in which we stop in a state from which we can enter production smoothly and cleanly. To do this, we could: - 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. Also, I think it is straightforward to introduce control file duplexing, with a second copy stored and maintained in the pg_xlog directory. This would provide additional protection for pg_control, which takes on more importance now that archive recovery is working. pg_xlog is a natural home, since on busy systems it's on its own disk away from everything else, ensuring that at least one copy survives. I can't see a downside to that, but others might... We can introduce user specifiable duplexing, in later releases. For later, I envisage an off-line utility that can be used to inspect xlog records. This could provide a number of features: - validate archived xlogs, to check they are sound. - produce summary reports, to allow identification of transactionIds and the effects of particular transactions - performance analysis to allow decisions to be made about whether group commit features could be utilised to good effect (Not now...) Best regards, Simon Riggs ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org