Re: recovery_connections cannot start (was Re: master in standby mode croaks)

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

In response to

Responses

Browse pgsql-hackers by date

  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)