Re: Using streaming replication as log archiving
От | Fujii Masao |
---|---|
Тема | Re: Using streaming replication as log archiving |
Дата | |
Msg-id | AANLkTimE6jw+wNBX83djx1BWJf8T3ip6+h8NEcUvuy9s@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Using streaming replication as log archiving (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Using streaming replication as log archiving
|
Список | 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 по дате отправления: