Hi, On Wed, Dec 24, 2008 at 1:48 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > > On Tue, 2008-12-23 at 17:42 +0200, Heikki Linnakangas wrote: > >> As the patch stands, whenever XLOG segment is switched in XLogInsert, we >> wait for the segment to be sent to the standby server. That's not good. >> Particularly in asynchronous mode, you'd expect the standby to not have >> any significant ill effect on the master. But in case of a flaky network >> connection, or a busy or dead standby, it can take a long time for the >> standby to respond, or the primary to give up. During that time, all WAL >> insertions on the primary are blocked. (How long is the default TCP >> timeout again?) > > Ugh, didn't see that. Get rid of that. We managed to get rid of the > fsync of the control file when we changed WAL file at start of 8.3. That > had a major effect on performance, via reduced response time profiles. > No need to re-introduce a delay in the same place.
Yes, I will get rid of it. It's only async case? both(async & sync)? >> For those reasons, we need a way to send arbitrary ranges of WAL from >> primary to standby. The current method where the WAL is read from >> wal_buffers obviously only works for very recent WAL pages that are >> still in wal_buffers. The design should be changed so that instead of >> reading from wal_buffers, the WAL is read from filesystem. Filesystem you say is only pg_xlog? If it includes archive, we might have to execute restore command in order to read WAL from filesystem? > If you are seriously suggesting these things now then I'd like to see > some diagrams, designs and descriptions so we can all understand what is > being suggested, how it will cope with all the current requirements. I also want. Regards, -- 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
