From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: recovery_connections cannot start (was Re: master in standby mode croaks) |
Date: | 2010-04-23 11:12:12 |
Message-ID: | 4BD1808C.9070301@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas wrote:
> On Fri, Apr 23, 2010 at 5:24 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)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, there's no difference between 2 and 3. (the "how many" aspect of 3
is controlled by max_wal_senders).
Let's have these three settings:
wal_mode = crash/archive/standby (replaces archive_mode)
archive_command
max_wal_senders
If wal_mode is set to 'crash', you can't set archive_command or
max_wal_senders>0. If it's set to 'archive', you can set archive_command
and/or max_wal_senders for archiving and streaming replication, but the
standby server won't allow queries. If you set it to 'standby', it will
(assuming you've set recovery_connections=on in the standby).
Note that "wal_mode=standby" replaces "recovery_connections=on" in the
primary.
I think this would be much easier to understand than the current
situation. I'm not wedded to the GUC name or values, though, maybe it
should be archive_mode=off/on/standby, or wal_mode=minimal/archive/full.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-04-23 11:21:39 | Re: recovery_connections cannot start (was Re: master in standby mode croaks) |
Previous Message | Robert Haas | 2010-04-23 10:44:39 | Re: recovery_connections cannot start (was Re: master in standby mode croaks) |