On Tue, Oct 26, 2010 at 2:57 PM, fazool mein <fazoolm...@gmail.com> wrote: > > On Tue, Oct 26, 2010 at 11:23 AM, Robert Haas <robertmh...@gmail.com> wrote: >> >> On Tue, Oct 26, 2010 at 2:13 PM, Heikki Linnakangas >> <heikki.linnakan...@enterprisedb.com> wrote: >> > >> >> Can you please describe why >> >> walsender reading directly from the buffers was given up? To avoid a >> >> lot >> >> of >> >> locking? >> > >> > To avoid locking yes, and complexity in general. >> >> And the fact that it might allow the standby to get ahead of the >> master, leading to silent database corruption. >> > > I agree that the standby might get ahead, but this doesn't necessarily lead > to database corruption. Here, the interesting case is what happens when the > primary fails, which can lead to *either* of the following two cases: > 1) The standby, due to some triggering mechanism, becomes the new primary. > In this case, even if the standby was ahead, its fine.
True. > 2) The primary comes back as primary. In this case, the standby will connect > again to the primary. At this point, *if* somehow we are able to detect that > the standby is ahead, then we should abort the standby and create a standby > from scratch. Unless you set restart_after_crash=off, the master could crash-and-restart before you can do anything about it. But that doesn't exist in the 9.0 branch. > I agree with Heikki that going through all this trouble only makes sense if > there is a huge performance boost. There's probably quite a large performance boost in the sync rep case from allowing the master and standby to fsync() in parallel, but first we need to get something that works at all. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
