Prev: Move tablespace
Next: pgsql: Make CheckRequiredParameterValues() dependupon correct
From: Simon Riggs on 23 Apr 2010 18:03
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(a)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


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Simon Riggs on 24 Apr 2010 05:32
On Fri, 2010-04-23 at 19:33 -0400, Robert Haas wrote:

> Principle of obvious breakage.

That is a good principle. It can be applied both ways here.

Changing user interfaces (or indeed, anything) to very little obvious
gain is a considerable annoyance to users. IIABDFI

We need to be aware of the timing issues on the project. Changing
something that has been the same for years is just annoying to existing
users and makes upgrading to our brand new shiny software much harder
than we ourselves would like that to be. But also, deferring solutions
to user problems for vague reasons also needs to be avoided because
waiting til next release moves the time to fix from about 6 months to
about 18 months on average, which crosses patience threshold. So in
general, I seek to speed up necessary change and slow down unnecessary
change requests. I think we're improving on both.

--
Simon Riggs www.2ndQuadrant.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Simon Riggs on 23 Apr 2010 12:24
On Fri, 2010-04-23 at 07:54 -0400, Robert Haas wrote:
> Let's
> revisit it for 9.1, and just improve the error reporting for now.

+1

--
Simon Riggs www.2ndQuadrant.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Heikki Linnakangas on 23 Apr 2010 14:21
Tom Lane wrote:
> We realized some time ago that it was a good idea to separate
> archive_mode (what to put in WAL) from archive_command (whether we are
> actually archiving right now). If we fail to apply that same principle
> to Hot Standby, I think we'll come to regret it.

The recovery_connections GUC does that. If you enable it, the extra
information required for hot standby is written to the WAL, otherwise
it's not.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Simon Riggs on 23 Apr 2010 14:55
On Fri, 2010-04-23 at 13:45 -0400, Robert Haas wrote:

> Archiving and streaming replication are
> just two means of transporting WAL records from point A to point B.

> By definition, any two manners of moving a byte stream around are
> isomorphic and can't possibly affect what that byte stream does or
> does not need to contain.

It is currently true, but there is no benefit in us constraining future
implementation routes without good reason.

--
Simon Riggs www.2ndQuadrant.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Move tablespace
Next: pgsql: Make CheckRequiredParameterValues() dependupon correct