> Bruce Momjian wrote
>
> P O S T G R E S Q L
>
> 8 . 0 O P E N I T E M S
>
a few comments...
> * add xid to log_line_prefix for PITR
This at first sounded like a wonderfully simple solution, though on
consideration, I'm not sure I'd recommend its use or ask for help in writing
it from the developer community.
First, it is an optional feature, and so won't help in the slightest when
you forgot to turn it on.
Second, as you mentioned when originally discussed, just because 123 has
committed, doesn't mean 122 has. So when the log line prefix shows 117 xid
for one log entry, then 123 for the next one...we really know nothing at all
about what happened between one log entry and the next and we would be
taking a stupid risk to say "I'll aim for 120 then".
Tom and I had previously discussed an offline xlog file inspection tool,
which almost got named...pg_xlogspy IIRC. The idea would be that you scan
the file to find out the contents, thereby allowing more informed decisions
about how to select your recovery target values. It's not written yet, I
know, but we (i.e. I) probably have time to make it work.
> * fix recovery of DROP TABLESPACE after checkpoint
Not something I have time, or sufficient immediate knowledge of to look into
this. Personally, I would just re-issue the statement...
Perhaps we're referring to the CREATE/DROP DATABASE not being logged?
Slightly different, its true.
Again, I would have to say, not enough time to learn how to make that
work... though it looks straightforward enough - need to re-create the
directory and make the correct catalog entries.
While reading/writing documentation, I'd been thinking some more about:
XLog File compression on archive
(opening a separate thread to discuss)
Best Regards, Simon Riggs