Re: V4 of PITR performance improvement for 8.4 - Mailing list pgsql-hackers

From Koichi Suzuki
Subject Re: V4 of PITR performance improvement for 8.4
Date
Msg-id a778a7260903101944s378d3b2p9da07707e4f17a04@mail.gmail.com
Whole thread Raw
In response to Re: V4 of PITR performance improvement for 8.4  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: V4 of PITR performance improvement for 8.4  (Koichi Suzuki <koichi.szk@gmail.com>)
List pgsql-hackers
Hi,

2009/3/10 Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>:
> Fujii Masao wrote:
>>
>> Hi,
>>
>> On Mon, Mar 9, 2009 at 10:20 PM, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.com> wrote:
>>>
>>> Thanks. This patch seems to be missing the new readahead.c file. I
>>> grabbed
>>> that from the previous patch version.
>>
>> Oh, sorry for the mistake. I changed one of Suzuki-san's patches
>> to be rebased to HEAD again (readahead-20090310.patch).
>> The other (addShBufCheck-20090120.patch) is not changed.
>>
>> Comment:
>> we might reach consistent recovery state *before* redoing the safe
>> starting point, because readahead slightly delays the actual redo.
>> Is this safe?
>
> No. If you haven't replayed all the WAL records up to the safe starting
> point, the database isn't consistent yet. The distinction doesn't matter in
> practice without Hot Standby, though.
>
>> If not, the readahead queue should be flushed before
>> reaching that state?
>
> Yes. Or you could move the reporting that you've reached the consistent
> recovery state into RedoRecords, when you reach the min safe starting point.

This arrangement can be done with Hot Standby and Sync.Rep, right?

So far, it sounds that we need to add a code to handle if malloc()
fails (OOM).   In this case, possible way could be to skip whole
readahead, although the rest of the recovery may fail because of the
memory shortage.

>
> --
>  Heikki Linnakangas
>  EnterpriseDB   http://www.enterprisedb.com
>



--
------
Koichi Suzuki


pgsql-hackers by date:

Previous
From: ITAGAKI Takahiro
Date:
Subject: Re: Sampling Profler for Postgres
Next
From: KaiGai Kohei
Date:
Subject: Updates of SE-PostgreSQL 8.4devel patches (r1710)