Re: Using streaming replication as log archiving - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Using streaming replication as log archiving
Date
Msg-id AANLkTimE6jw+wNBX83djx1BWJf8T3ip6+h8NEcUvuy9s@mail.gmail.com
Whole thread Raw
In response to Re: Using streaming replication as log archiving  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Using streaming replication as log archiving
List pgsql-hackers
On Wed, Sep 29, 2010 at 5:47 PM, Magnus Hagander <magnus@hagander.net> wrote:
> It's actually intentional. If we create a file at first, there is no
> way to figure out exactly how far through a partial segment we are
> without parsing the details of the log. This is useful both for the
> admin (who can look at the directory and watch the file grow) and the
> tool itself (to know when the .save file can be rotated away, when
> recovering from a partial segment receive).
>
> My idea was to just have the admin pad the file when it's time to do
> the restore. I could perhaps even add an option to the tool to do it -
> the idea being it's a manual step still.
>
> Do you have another suggestion for how to provide those two things?

My idea is to implement something like xlogdump in contrib and use it
for those two things. Though it's harder to implement that than to do
padding tool.

BTW, implementing something like xlogdump is already in TODO list:

---
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.
http://wiki.postgresql.org/wiki/TODO#Point-In-Time_Recovery_.28PITR.29
---

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: wip: functions median and percentile
Next
From: Fujii Masao
Date:
Subject: Re: recovery.conf location