pg.ddx.io  pgsql-docs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Simon Riggs <simon@2ndquadrant.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Richard Huxton <dev@archonet.com>
Cc: pgsql-docs@postgresql.org
Subject: Re: Proposed doc-patch: Identifying the Current WAL file
Date: Sun, 16 Apr 2006 15:22:05 +0100
Message-ID: <1145197325.3273.37.camel@localhost.localdomain> (raw)
In-Reply-To: <200604152020.k3FKKjM20502@candle.pha.pa.us>
References: <200604152020.k3FKKjM20502@candle.pha.pa.us>

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/




view thread (27+ messages)  latest in thread

Message-ID: <1145197325.3273.37.camel@localhost.localdomain>
Permalink:  ../1145197325.3273.37.camel@localhost.localdomain/
Also on:    postgresql.org/message-id/1145197325.3273.37.camel@localhost.localdomain

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-docs@postgresql.org
  Cc: simon@2ndquadrant.com, pgman@candle.pha.pa.us, tgl@sss.pgh.pa.us, dev@archonet.com
  Subject: Re: Proposed doc-patch: Identifying the Current WAL file
  In-Reply-To: <1145197325.3273.37.camel@localhost.localdomain>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox