| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | Koichi Suzuki <koichi(dot)szk(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: V4 of PITR performance improvement for 8.4 |
| Date: | 2009-03-10 12:03:10 |
| Message-ID: | 49B656FE.4090609@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Fujii Masao wrote:
> Hi,
>
> On Mon, Mar 9, 2009 at 10:20 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-03-10 12:04:35 | Re: Sampling Profler for Postgres |
| Previous Message | Gregory Stark | 2009-03-10 11:48:32 | Re: Updates of SE-PostgreSQL 8.4devel patches (r1704) |