Thanks a lot for the comment/advice. Yes, full page backup block
considerablly shortens the recovery time. As we discussed about two
years ago, I have a solution accelerate the recovery even without full
page image. I'd like to submit this solution to the community again. When I evaluated this two years ago, recovery
speedwas as good as
those with full page image, depending upon application and tuning, of
course.
This is a separate tool and can be used in various scenes.
Regards;
----------
Koichi Suzuki
2010/5/13 Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>:
>
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> Bruce Momjian <bruce@momjian.us> writes:
>> > Yes, I would love to get this into /contrib for PG 9.1!
>>
>> How much are people really going to care about pg_lesslog now that
>> we've got streaming replication? There might be some small use-case
>> still left, but it's hard to believe that it would be worth carrying
>> it in contrib.
>
> I hope pg_lesslog would work as a WAL filter of streaming replication.
> It might be hard-coded in WAL sender, or be an addon based on a new
> common filtering infrastructure of WAL streaming.
>
> Also, there is a long-standing issue in pg_lesslog; It slows down recovery
> because we need to read data pages before write in recovery. We're avoiding
> reading pages for full-page image in 8.3, but pg_lesslog will disable
> the optimization. Recovery routine in core also needs to be adjusted to use
> read-ahead, like posix_fadvise().
>
> There was another idea, full-page image logs separated with WAL logging.
> In theory, full-page images don't have to be written at commit, but only
> by writing corresponding data pages, I'm not sure whether it is an actually
> good idea or not, but if we go the direction, we won't need pg_lesslog.
>
> Regards,
> ---
> Takahiro Itagaki
> NTT Open Source Software Center
>
>
>