Hi, On Mon, Dec 8, 2008 at 2:54 PM, Koichi Suzuki <[EMAIL PROTECTED]> wrote: > I understood your point. In the case of synchronous replication, > because slave fails over when master crashes, there're no need to > leave FPW from the beginning. > > In this case, only prefetch will work. Fujii's code at the slave > looks very similar to pg_standby and pg_readahead will help in this > case with no modification.
As the result of discussion, I will change the way to recover on the standby; we don't use PITR for the WAL which walreceiver received, instead, startup process read it by *record* from pg_xlog and redo. So, I'm afraid that synchronous replication doesn't match well with pg_readahead. Regards, > > 2008/12/4 Simon Riggs <[EMAIL PROTECTED]>: >> >> On Wed, 2008-12-03 at 14:22 +0900, Koichi Suzuki wrote: >> >>> > There's clearly a huge gain using prefetch, when we have >>> > full_page_writes = off. But that does make me think: Why do we need >>> > prefetch at all if we use full page writes? There's nothing to prefetch >>> > if we can keep it in cache. >>> >>> Agreed. This is why I proposed prefetch optional through GUC. >>> >>> > So I'm wondering if we only need prefetch because we're using lesslog? >>> > >>> > If we integrated lesslog better into the new replication would we be >>> > able to forget about doing the prefetch altogether? >>> >>> In the case of lesslog, almost all the FPW is replaced with >>> corresponding incremental log and recovery takes longer. Prefetch >>> dramatically improve this, as you will see in the above result. To >>> improve recovery time with FPW=off or FPW=on and lesslog=yes, we need >>> prefetch. >> >> It does sound like it is needed, yes. But if you look at the >> architecture of synchronous replication in 8.4 then I don't think it >> makes sense any more. It would be very useful for the architecture we >> had in 8.3, but that time has gone. >> >> If we have FPW=on on primary then we will stream WAL with FPW to >> standby. There seems little point removing it *after* it has been sent, >> then putting it back again before we recover, especially when it causes >> a drop in performance that then needs to be fixed (by this patch). >> >> pg_lesslog allowed us to write FPW to disk, yet send WAL without FPW. >> >> So if we find a way of streaming WAL without FPW then this patch makes >> sense, but not until then. So far many people have argued in favour of >> using FPW=on, which was the whole point of pg_lesslog. Are we now saying >> that we would run the primary with FPW=off? >> >> -- >> Simon Riggs www.2ndQuadrant.com >> PostgreSQL Training, Services and Support >> >> > > > > -- > ------ > Koichi Suzuki > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers