Robert Haas wrote: > On Fri, Apr 23, 2010 at 7:12 AM, Heikki Linnakangas > <heikki.linnakan...@enterprisedb.com> wrote: >> Robert Haas wrote: >>> On Fri, Apr 23, 2010 at 5:24 AM, Heikki Linnakangas >>> <heikki.linnakan...@enterprisedb.com> wrote: >>>> I quite liked Robert's proposal to add an explicit GUC to control what >>>> extra information is logged >>>> (http://archives.postgresql.org/pgsql-hackers/2010-04/msg00509.php). It >>>> is quite difficult to explain the current behavior, a simple explicit >>>> wal_mode GUC would be a lot simpler. It wouldn't add any extra steps to >>>> setting the system up, you currently need to set archive_mode='on' >>>> anyway to enable archiving. You would just set wal_mode='archive' or >>>> wal_mode='standby' instead, depending on what you want to do with the WAL. >>> I liked it, too, but I sort of decided it didn't buy much. There are >>> three separate sets of things that need to be controlled: >>> >>> 1. What WAL to emit - (a) just enough for crash recovery, (b) enough >>> for log shipping, (c) enough for log shipping with recovery >>> connections. >>> >>> 2. Whether to run the archiver. >>> >>> 3. Whether to allow streaming replication connections (and if so, how many). >> Streaming replication needs the same information in the WAL as archiving >> does, > > True. > >> there's no difference between 2 and 3. (the "how many" aspect of 3 >> is controlled by max_wal_senders). > > False. > > I thought what you think too, but discovered otherwise when I read the > code. Some uses of archive_mode are used to control what WAL is > generated, but others control a *process* called the archiver.
Hmm, never mind the archiver process, we could just launch it always and it would just sit idle if archive_command was not set. But a more serious concern is that if you set "archive_mode=on", and "archive_command=''", we retain all WAL indefinitely, because it's not being archived, until you set archive_command to something that succeeds again. You're right, with the wal_mode='crash/archive/standby" there would be no way to distinguish "archiving is temporarily disabled, keep all accumulated WAL around" and "we're not archiving, but wal_mode='archive' to enable streaming replication". Ok, that brings us back to square one. We could still add the wal_mode GUC to explicitly control how much WAL is written (replacing recovery_connections in the primary), I think it would still make the system easier to explain. But it would add an extra hurdle to enabling archiving, you'd have to set wal_mode='archive', archive_mode='on', and archive_command. I'm not sure if that would be better or worse than the current situation. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
