On Sat, 2006-04-15 at 16:20 -0400, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Sat, 2006-04-15 at 12:24 -0400, Bruce Momjian wrote:
> > > And if we can't provide one, should we supply an SQL function
> > > to return the current WAL name?
> >
> > I'll do this. Just give me a few days to get my feet under the new desk.
> > I know its well past time I sorted this and a few other things out.
>
> If we get some mechanism to write those partial WAL files, we might not
> need the ability to identify the current WAL file, and because a new
> function is going to require an initdb, I am thinking we can't get this
> done until 8.2 anyway, so Simon, please come up with a plan to finish
> the missing PITR pieces. I am getting tired of trying to explain
> workarounds to PITR users, especially when the workarounds are not easy.
>
> We added PITR in 8.0, and we have made little improvement to it since
> then, and its limitations are getting tiring.
Yes, I know all of this, thats why I'm pleased to be in a position to
change this, now that I don't have a day job ;-). (Having said this, I'm
in California all week, so give me a little longer).
For 8.0. and 8.1 users, I'd suggest we release an external function as a
contrib module, so that we don't compromise reliability and not force an
initdb for them. With docs, of course.
I suggest we have two functions:
1. pg_xlog_file_from_offset(text)
This allows the output of pg_stop_backup to be formatted into a
filename, so it would be used like this:
select pg_xlog_file_from_offset(pg_stop_backup());
2. pg_xlog_file_current()
Can be run at any time to find the current xlog file
We need both because we need to know the current xlog file at the time
stop backup was run, not just at the time the function was executed. But
we may need the second function at other times.
For 8.2 we definitely need the logswitch logic to function at time of
pg_stop_backup() - and this should not return until archiver has
successfully copied the switched file away. 8.2 can have function (2)
internally in case anyone cares. (I agree, f(1) would be redundant at
that point).
(I'll let you guys decide the function names.)
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com/
