On Tue, Jun 15, 2010 at 12:46 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Mon, Jun 14, 2010 at 10:13 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Mon, Jun 14, 2010 at 8:41 AM, Fujii Masao <masao.fu...@gmail.com> wrote: >>> On Mon, Jun 14, 2010 at 8:10 PM, Robert Haas <robertmh...@gmail.com> wrote: >>>> Maybe. That sounds like a pretty enormous foot-gun to me, considering >>>> that we have no way of recovering from the situation where the standby >>>> gets ahead of the master. >>> >>> No, we can do that by reconstructing the standby from the backup. >>> >>> And, that situation is not a problem for users including me who prefer to >>> perform a failover when the master goes down. >> >> You don't get to pick - if a backend crashes on the master, it will >> restart right away and come up, but the slave will now be hosed... > > You are concerned about the case where postmaster automatically restarts > the crash recovery, in particular? Yes, this case is more problematic. > If the standby is ahead of the master, the standby might find an invalid > record and run into the infinite retry loop, or keep working without > noticing the inconsistency between the database and the WAL. > > I'm thinking that walreceiver should throw a PANIC when it receives the > record which is in the LSN older than the last WAL receive location, > except the beginning of streaming (because the standby always requests > for streaming from the starting of WAL file at first even if some records > have already been received in previous time). Thought?
Yeah, that seems like it would be a good safety check. I wonder if it would be possible to jigger things so that we send the WAL to the standby as soon as it is generated, but somehow arrange things so that the standby knows the last location that the master has fsync'd and never applies beyond that point. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
