Prev: Move tablespace
Next: pgsql: Make CheckRequiredParameterValues() dependupon correct
From: Heikki Linnakangas on 23 Apr 2010 16:10
Tom Lane wrote:
> Robert Haas <robertmhaas(a)gmail.com> writes:
>> ... I'm still unconvinced of our ability to come
>> up with a solid design in the time we have, but I think it would make
>> sense to listen to proposals people want to make. I poked some holes
>> in Heikki's design from this morning (which was, more or less, my
>> design from last week) but that doesn't mean they can't be plugged.
>
> The only hole I saw poked was the one about how archive_mode is used to
> decide whether to start the archiver process. I think we could
> reasonably deal with that by starting the archiver iff wal_mode > 'crash'.
> There's no point in archiving otherwise, and the overhead of an idle
> archiver is small enough that we can live with the corner cases where
> you're starting an archiver you don't really need.

Agreed, but a more serious hole is what I pointed out at
http://archives.postgresql.org/message-id/4BD18722.3090608(a)enterprisedb.com.
That is, if you do:

wal_mode=standby
archive_command=''
max_wal_senders=5

That would be a valid configuration for enabling streaming replication
without archiving (which is possible and reasonable if you set the new
wal_keep_segments setting high enough). But as things stand, WAL
segments would be readied for archiving (.ready files would be created),
but they'e never archived and will accumulate indefinitely in the
master. You could work around that with archive_command='/usr/bin/true',
but that's not user-frienfly.

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'

replication_connections is not needed on the master anymore; on the
standby it enables/disables hot standby. It is ignored on the master, to
allow the same configuration file to be used on master and standby.

--
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 16:05
On Fri, 2010-04-23 at 14:56 -0500, Kevin Grittner wrote:
> Simon Riggs <simon(a)2ndQuadrant.com> wrote:
>
> > So we're proposing adding parameters to simplify things for users?
>
> I think it's a matter of having parameters which do simple, clear
> things; rather than magically interacting to guess what the user
> wants. What do you want to log? How many connections to you want
> to allow for streaming it? What's your script for sending it in
> archive file format? Is archiving turned on at the moment? Let's
> have GUC for each question, rather than having to work backwards
> from what you want to which combination of GUC settings gets you to
> that, or at least as close as the magic interpretation allows.

I've just committed a change to make Hot Standby depend only upon
the setting "recovery_connections = on" on the master. That makes it
clear that there is one lever, not lots of confusing ones.

That might forestall further changes, because the correct way of doing
this was already as simple as people wanted it to be. The previous
requirement was actually a bug: the method of WAL delivery has nothing
at all to do with Hot Standby (currently).

Not intended to stop further debate, if people wish.

--
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 16:31
On Fri, 2010-04-23 at 23:10 +0300, Heikki Linnakangas wrote:
> So my proposal would be:
>
> wal_mode=crash/archive/standby

OK, I agree to change in this area.

I definitely don't like the word "crash", which may scare and confuse
people. I don't think I would ever set any parameter to a word like
"crash" since it isn't clear whether it allows that event or protects
against it. Also, I don't like the word "standby" on its own, since that
has already been used for Warm Standby for some time, which corresponds
to the "archive" setting and is therefore confusing.

How about something like

wal_additional_info = none | archive | connect

Then its easy to understand that things slow down when you request
additional information in the WAL, and also clear that Hot Standby
requires slightly more info on top of that. It's also clear that this
has nothing at all to do with the delivery mechanism.

--
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 17:26
On Fri, 2010-04-23 at 16:50 -0400, Tom Lane wrote:
> Simon Riggs <simon(a)2ndQuadrant.com> writes:
> > How about something like
>
> > wal_additional_info = none | archive | connect
>
> "connect" seems like a completely inappropriate word here. It is
> not obviously related to HS slaves and it could be taken to refer
> to ordinary database connections (sessions).
>
> Personally I agree with your objection to "crash" but not with the
> objection to "standby". Maybe this would be appropriate:
>
> wal_mode = minimal | archive | hot_standby

Sounds good, I'll go for that.


In my understanding this means that archive_mode does completely and the
max_wal_senders does not affect WAL contents?

Does that mean that wal_mode can be SIGHUP now? It would be good. I
think this is how to do that:
At the start of every WAL-avoiding operation we could take a copy of
wal_mode for the server and store in MyProc->wal_mode. At transaction
start we would set that to "not set". We could then make
pg_start_backup() wait for all transactions with wal_mode set to
complete before we continue.

--
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 17:38
On Fri, 2010-04-23 at 17:29 -0400, Robert Haas wrote:
> Possible "crash_recovery" rather than just "crash" where you have
> "mimimal".

Minimal is good because it is a performance option also, which is an
aspect "crash_recovery" does not convey.

(Plus we use the word crash again, which is too scary to use)

--
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

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