Re: recovery_connections cannot start (was Re: master in standby mode croaks) - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: recovery_connections cannot start (was Re: master in standby mode croaks)
Date
Msg-id 1272060236.4161.844.camel@ebony
Whole thread Raw
In response to Re: recovery_connections cannot start (was Re: master in standby mode croaks)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: recovery_connections cannot start (was Re: master in standby mode croaks)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 2010-04-23 at 17:43 -0400, Robert Haas wrote:
> On Fri, Apr 23, 2010 at 4:10 PM, Heikki Linnakangas
> <heikki.linnakangas@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".

We don't need *both* wal_mode and archive_mode, since archive_mode
exists only to ensure that full WAL is written even when archive_command
= '' momentarily.

Should do this

> > wal_mode=crash/archive/standby
> > archive_command='command'
> > max_wal_senders=<integer>       # if > 0, wal_mode must be >= 'archive'

and make wal_mode SIGHUP

-- Simon Riggs           www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: recovery_connections cannot start (was Re: master in standby mode croaks)
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct