On Fri, 2010-09-17 at 20:56 +0900, Fujii Masao wrote: > On Fri, Sep 17, 2010 at 7:41 PM, Heikki Linnakangas > <heikki.linnakan...@enterprisedb.com> wrote: > >> The question is do we want standby registration on master and if so, > >> why? > > > > Well, aside from how to configure synchronous replication, standby > > registration would help with retaining the right amount of WAL in the > > master. wal_keep_segments doesn't guarantee that enough is retained, and > > OTOH when all standbys are connected you retain much more than might be > > required. > > Yep.
Setting wal_keep_segments is difficult, but its not a tunable. The sysadmin needs to tell us what is the maximum number of files she'd like to keep. Otherwise we may fill up a disk, use space intended for use by another app, etc.. The server cannot determine what limits the sysadmin may wish to impose. The only sane default is 0, because "store everything, forever" makes no sense. Similarly, if we register a server, it goes down and we forget to deregister it then we will attempt to store everything, forever and our system will go down. The bigger problem is base backups, not server restarts. We don't know how to get that right because we don't register base backups automatically. If we did dynamically alter the number of WALs we store then we'd potentially screw up new base backups. Server registration won't help with that at all, so you'd need to add a base backup registration scheme as well. But even if you had that, you'd still need a "max" setting defined by sysadmin. So the only sane thing to do is to set wal_keep_segments as high as possible. And doing that doesn't need server reg. > And standby registration is required when we support "wait forever when > synchronous standby isn't connected at the moment" option that Heikki > explained upthread. Though I don't think that standby registration is > required in the first phase since "wait forever" option is not used in > basic use case. Synchronous replication is basically used to reduce the > downtime, and "wait forever" option opposes that. Agreed, but I'd say "if" we support that. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers