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
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 |