Robert Haas wrote:
> On Fri, Apr 23, 2010 at 7:12 AM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> Robert Haas wrote:
>>> On Fri, Apr 23, 2010 at 5:24 AM, Heikki Linnakangas
>>> <heikki.linnakangas@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
