Thread

1. WAL dump tool

   higepon <higepon@gmail.com> — 2009-05-08T08:43:11Z

   Hi.
   Is the following todo item still necessary?
   
     Create dump tool for write-ahead logs for use in determining
   transaction id for point-in-time recovery.
       This is useful for checking PITR recovery.
   
   If so, I want to make it.
   What is the expected output of the dump tool?
   TransactionId, TimeLineID and ?
   
   
   Best regards,
   
   -----
   MINOWA Taro (Higepon)
   
   Cybozu Labs, Inc.
   
   http://www.monaos.org/
   http://code.google.com/p/mosh-scheme/
   
   

2. Re: WAL dump tool

   Jaime Casanova <jcasanov@systemguards.com.ec> — 2009-05-09T04:20:43Z

   On Fri, May 8, 2009 at 3:43 AM, higepon <higepon@gmail.com> wrote:
   > Hi.
   > Is the following todo item still necessary?
   >
   >  Create dump tool for write-ahead logs for use in determining
   > transaction id for point-in-time recovery.
   >    This is useful for checking PITR recovery.
   >
   > If so, I want to make it.
   > What is the expected output of the dump tool?
   > TransactionId, TimeLineID and ?
   >
   
   don't know if this project ever works
   http://pgfoundry.org/projects/xlogviewer but seems like is a start (it
   was made for 8.2 so you will have to adjust for 8.3 or even better
   8.4)
   
   
   -- 
   Atentamente,
   Jaime Casanova
   Soporte y capacitación de PostgreSQL
   Asesoría y desarrollo de sistemas
   Guayaquil - Ecuador
   Cel. +59387171157
   
   

3. Re: WAL dump tool

   Robert Treat <xzilla@users.sourceforge.net> — 2009-05-10T05:23:44Z

   On Saturday 09 May 2009 00:20:43 Jaime Casanova wrote:
   > On Fri, May 8, 2009 at 3:43 AM, higepon <higepon@gmail.com> wrote:
   > > Hi.
   > > Is the following todo item still necessary?
   > >
   > >  Create dump tool for write-ahead logs for use in determining
   > > transaction id for point-in-time recovery.
   > >    This is useful for checking PITR recovery.
   > >
   > > If so, I want to make it.
   > > What is the expected output of the dump tool?
   > > TransactionId, TimeLineID and ?
   >
   > don't know if this project ever works
   > http://pgfoundry.org/projects/xlogviewer but seems like is a start (it
   > was made for 8.2 so you will have to adjust for 8.3 or even better
   > 8.4)
   >
   >
   
   It did work at one point. We used it for some disaster recovery work maybe a 
   year or so ago. We had to update it for 8.3, and remove some linuxisms to get 
   it to compile for Solaris. I think it might have still had issues actually 
   dumping data, but it did do a good job at finding corrupted xlogs.  istr Theo 
   submitted a patch, but I think the author had abandoned it. Personally I'd 
   love to see it moved into postgresql proper (and get the cleaning/updating 
   that implies). 
   
   -- 
   Robert Treat
   Conjecture: http://www.xzilla.net
   Consulting: http://www.omniti.com
   
   

4. Re: WAL dump tool

   Rodrigo E. De León Plicet <rdeleonp@gmail.com> — 2009-05-18T04:45:18Z

   On Sun, May 10, 2009 at 12:23 AM, Robert Treat
   <xzilla@users.sourceforge.net> wrote:
   > On Saturday 09 May 2009 00:20:43 Jaime Casanova wrote:
   >> On Fri, May 8, 2009 at 3:43 AM, higepon <higepon@gmail.com> wrote:
   >> > Hi.
   >> > Is the following todo item still necessary?
   >> >
   >> >  Create dump tool for write-ahead logs for use in determining
   >> > transaction id for point-in-time recovery.
   >> >    This is useful for checking PITR recovery.
   >> >
   >> > If so, I want to make it.
   >> > What is the expected output of the dump tool?
   >> > TransactionId, TimeLineID and ?
   >>
   >> don't know if this project ever works
   >> http://pgfoundry.org/projects/xlogviewer but seems like is a start (it
   >> was made for 8.2 so you will have to adjust for 8.3 or even better
   >> 8.4)
   >
   > It did work at one point. We used it for some disaster recovery work maybe a
   > year or so ago. We had to update it for 8.3, and remove some linuxisms to get
   > it to compile for Solaris. I think it might have still had issues actually
   > dumping data, but it did do a good job at finding corrupted xlogs.  istr Theo
   > submitted a patch, but I think the author had abandoned it. Personally I'd
   > love to see it moved into postgresql proper (and get the cleaning/updating
   > that implies).
   
   Would this allow functionality similar to that of LogMiner (
   http://www.oracle.com/technology/deploy/availability/htdocs/LogMinerOverview.htm
   ), or is it something else entirely?