Re: Using streaming replication as log archiving

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Using streaming replication as log archiving
Date: 2010-10-01 09:13:02
Message-ID: AANLkTimE6jw+wNBX83djx1BWJf8T3ip6+h8NEcUvuy9s@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 29, 2010 at 5:47 PM, Magnus Hagander <magnus(at)hagander(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2010-10-01 09:47:45 Re: recovery.conf location
Previous Message Pavel Stehule 2010-10-01 08:46:45 Re: wip: functions median and percentile