Re: Documenting pglesslog

From: "Koichi Suzuki" <koichi(dot)szk(at)gmail(dot)com>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Documenting pglesslog
Date: 2009-01-14 04:03:18
Message-ID: a778a7260901132003r7b357360n174c736e88101a64@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>

--
------
Koichi Suzuki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Chernow 2009-01-14 04:09:34 Re: solaris libpq threaded build fails
Previous Message Stephen Frost 2009-01-14 03:53:43 Re: A single escape required for log_filename