On Fri, Apr 23, 2010 at 6:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Apr 23, 2010 at 4:10 PM, Heikki Linnakangas >> <heikki.linnakan...@enterprisedb.com> wrote: >>> So my proposal would be: >>> >>> wal_mode=crash/archive/standby >>> archive_mode=on/off # if on, wal_mode must be >= 'archive' >>> archive_command='command' >>> max_wal_senders=<integer> # if > 0, wal_mode must be >= 'archive' > >> As a general design comment, I think we should avoid still having an >> archive_mode GUC but having it do something different. If we're going >> to change the semantics, we should also change the name, maybe to >> "archiving". > > Agreed on the general point, but AFAICS that proposal keeps the meaning > of archive_mode the same as it was.
Well, clearly it doesn't. Someone who thinks they can simply turn archive_mode=on and set archive_command is going to be sadly disappointed. Before, archive_mode arguably switched the server between two "modes", with a whole set of behaviors associated with it: type of WAL logging, whether the archive runs, number of WAL segments maintained. Under any of the proposals on the table (other than, "just adjust the error message", which still seems tempting) it's new purview will be more limited. ...Robert ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
