Re: Documenting pglesslog - Mailing list pgsql-hackers

From Koichi Suzuki
Subject Re: Documenting pglesslog
Date
Msg-id a778a7260901132003r7b357360n174c736e88101a64@mail.gmail.com
Whole thread Raw
In response to Re: Documenting pglesslog  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Documenting pglesslog  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Pg_readahead is a tool to prefetch data pages before redoing, based on
the contents of archive/active WAL segment.   For 8.3 and 8.4 without
sync.rep, this works together with restore_command.   Pg_readahead
analyze WAL segment, schedule and issue posix_fadvise() to prefetch
data pages quickly before redoing.

Discussions and materials will be found at

http://archives.postgresql.org/pgsql-hackers/2008-10/msg01372.php

So far, external command implemantation speeds up PITR up to six
times!  Therefore, overall recovery time can be a little longer than
that with FPW.


2009/1/14 Bruce Momjian <bruce@momjian.us>:
> Koichi Suzuki wrote:
>> Hi,
>>
>> I have no intention to make pglesslog to conflict to PostgreSQL
>> license.   Any advice is welcome to make pglesslog available without
>> any license concern.
>
> I certainly have no concerns.
>
>> I've a question and ideas.
>>
>> Bruce's modification directly points to my pgfoundry page.   I'm not
>> sure what it means.  Does it mean that I have to maintain the page for
>> a while?   If pglesslog helps for future releases, can it be a part of
>> PostgreSQL release, as contrib module so that all the documentation in
>> pgfoundry (although very simple) is included in the release material?
>
> I think eventually we should put pglesslog into /contrib, and if we ever
> do that, we would update your web page.  I have not heard any mention of
> it being moved into /contrib for 8.4 though.
>
> If you would like me to point to another URL, please let me know.
>
> I think there is definately demand for pglesslog because not only does
> it truncate dead space from the WAL file, it also removes full page
> write images, and is best done in archive_command, and hence externally
> like your tool does.
>
>> As many hackers know, I've posted another code to speedup PITR after
>> slipping FPW, which does work with 8.3 as external module
>> (pg_readahead).   I'm now working to work this with synchronous
>> replication.   Maybe it's a good idea to use pglesslog with
>> pg_readahead.    Although I'm not sure if pg_readahead integration
>> with synchronous replication will be done within 8.4 development
>> period, I'm quite ready to post pg_readahead for 8.4 sililar to that
>> for 8.3, which also could be in contrib module.
>
> Sorry, I don't know enough about pg_readahead.
>
> --
>  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>  EnterpriseDB                             http://enterprisedb.com
>
>  + If your life is a hard drive, Christ can be your backup. +
>



-- 
------
Koichi Suzuki


pgsql-hackers by date:

Previous
From: Andrew Chernow
Date:
Subject: Re: solaris libpq threaded build fails
Next
From: "Robert Haas"
Date:
Subject: Re: A single escape required for log_filename