On Fri, Apr 23, 2010 at 4:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, I think the real hole is that turning archive_mode=on results in
WAL never being deleted unless it's successfully archived.
Hm, good point. And at least in principle you could
Tom Lane wrote:
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
Ok, here's a patch implementing this proposal. It adds a new wal_mode
setting, leaving archive_mode as it
Robert Haas wrote:
On Fri, Apr 23, 2010 at 4:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, I think the real hole is that turning archive_mode=on results in
WAL never being deleted unless it's successfully archived.
Hm, good point. And at least in
On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Tom Lane wrote:
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
Ok, here's
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
* How about naming the parameter wal_level instead of wal_mode? That
would better convey that the higher levels add stuff on top of the lower
levels,
On Mon, Apr 26, 2010 at 10:23 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
* How about naming the parameter wal_level instead of wal_mode? That
would better
Folks,
(a) is this checked in yet?
(b) should we delay Beta to test it?\
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sent via pgsql-hackers mailing list
On Mon, Apr 26, 2010 at 2:15 PM, Josh Berkus j...@agliodbs.com wrote:
(a) is this checked in yet?
No.
(b) should we delay Beta to test it?\
I suspect it's going to be checked in pretty soon, so that may not be
necessary. Not my call, though.
...Robert
--
Sent via pgsql-hackers mailing
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
Fujii Masao wrote:
On Fri, Apr 23, 2010 at 1:04 AM, Robert Haas robertmh...@gmail.com wrote:
One way we could fix this is use 2 bits rather than 1 for
XLogStandbyInfoMode. One bit could indicate that either
archive_mode=on or max_wal_senders0, and the second bit could
indicate that
On Fri, Apr 23, 2010 at 5:24 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Fri, Apr 23, 2010 at 1:04 AM, Robert Haas robertmh...@gmail.com wrote:
One way we could fix this is use 2 bits rather than 1 for
XLogStandbyInfoMode. One bit could indicate
Robert Haas wrote:
On Fri, Apr 23, 2010 at 5:24 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.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
On Fri, Apr 23, 2010 at 7:12 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
On Fri, Apr 23, 2010 at 5:24 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I quite liked Robert's proposal to add an explicit GUC to control what
extra
Robert Haas wrote:
On Fri, Apr 23, 2010 at 7:12 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
On Fri, Apr 23, 2010 at 5:24 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I quite liked Robert's proposal to add an explicit GUC to
On Apr 23, 2010, at 13:12 , Heikki Linnakangas wrote:
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_senders0. If it's set to 'archive', you
On Fri, Apr 23, 2010 at 7:40 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Ok, that brings us back to square one. We could still add the wal_mode
GUC to explicitly control how much WAL is written (replacing
recovery_connections in the primary), I think it would still make
On Fri, Apr 23, 2010 at 8:54 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Apr 23, 2010 at 7:40 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Ok, that brings us back to square one. We could still add the wal_mode
GUC to explicitly control how much WAL is written
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 23, 2010 at 7:12 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Streaming replication needs the same information in the WAL as archiving
does,
True.
FWIW, I still don't believe that claim, and I think it's complete
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@postgresql.org)
To make changes to your subscription:
On Fri, Apr 23, 2010 at 12:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 23, 2010 at 7:12 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Streaming replication needs the same information in the WAL as archiving
does,
True.
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 23, 2010 at 12:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, I still don't believe that claim, and I think it's complete folly
to set the assumption in stone by choosing a user-visible GUC API that
depends on it being true.
Huh? We're
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
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
On Fri, Apr 23, 2010 at 2:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
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
Tom Lane t...@sss.pgh.pa.us wrote:
As a concrete example, there is nothing logically wrong with
driving a hot standby slave from WAL records shipped via old-style
pg_standby. Or how about wanting to turn off recovery_connections
temporarily, but not wanting the archived WAL to be unable to
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
On Fri, Apr 23, 2010 at 2:43 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
As a concrete example, there is nothing logically wrong with
driving a hot standby slave from WAL records shipped via old-style
pg_standby. Or how about wanting to turn off
On Fri, 2010-04-23 at 15:05 -0400, Robert Haas wrote:
we have a consensus behind changing it, which it's starting to
sound like we do.
I think you misread the +1s from Masao and myself.
Those confusing things are options and I want them to remain optional,
not compressed into a potentially too
On Fri, Apr 23, 2010 at 3:11 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2010-04-23 at 15:05 -0400, Robert Haas wrote:
we have a consensus behind changing it, which it's starting to
sound like we do.
I think you misread the +1s from Masao and myself.
Those confusing things are
Simon Riggs si...@2ndquadrant.com writes:
Those confusing things are options and I want them to remain optional,
not compressed into a potentially too simple model based upon how the
world looks right now.
What are you arguing is too simple? What *I* think is too simple is
what we have got
Robert Haas robertmh...@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,
On Fri, 2010-04-23 at 15:18 -0400, Robert Haas wrote:
We're going to need
a bunch of GUCs any way we slice it. The issue is whether there's a
way to slice it that involves fewer AND and OR operators that have to
be understood by users.
So we're proposing adding parameters to simplify things
Simon Riggs si...@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
Simon Riggs si...@2ndquadrant.com writes:
So we're proposing adding parameters to simplify things for users?
Not so much simplify as make understandable; although flexibility
is a concern too.
I'm guessing this conversation has more to do with the situation that
some very clever people have a
On Fri, Apr 23, 2010 at 3:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@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
On Fri, 2010-04-23 at 14:56 -0500, Kevin Grittner wrote:
Simon Riggs si...@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
Tom Lane wrote:
Robert Haas robertmh...@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
Robert Haas robertmh...@gmail.com writes:
Well, I think the real hole is that turning archive_mode=on results in
WAL never being deleted unless it's successfully archived.
Hm, good point. And at least in principle you could have SR setups
that don't care about having a backing WAL archive.
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
Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2010-04-23 at 23:10 +0300, Heikki Linnakangas wrote:
So my proposal would be:
wal_mode=crash/archive/standby
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
Simon Riggs si...@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).
On Fri, Apr 23, 2010 at 4:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@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
On Fri, 2010-04-23 at 16:50 -0400, Tom Lane wrote:
Simon Riggs si...@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
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
On Fri, Apr 23, 2010 at 4:10 PM, Heikki Linnakangas
heikki.linnakan...@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,
On Fri, 2010-04-23 at 17:43 -0400, Robert Haas wrote:
On Fri, Apr 23, 2010 at 4:10 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
So my proposal would be:
wal_mode=crash/archive/standby
archive_mode=on/off # if on, wal_mode must be = 'archive'
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 23, 2010 at 4:10 PM, Heikki Linnakangas
heikki.linnakan...@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'
Simon Riggs si...@2ndquadrant.com writes:
In my understanding this means that archive_mode does completely and the
max_wal_senders does not affect WAL contents?
I think we'd concluded that we have to keep archive_mode as a separate
boolean. (Or we could use Heikki's idea of a max number of
Simon Riggs si...@2ndquadrant.com writes:
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.
No, you missed the point of the upthread discussion: archive_mode
controls whether to start
On Fri, Apr 23, 2010 at 6:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 23, 2010 at 4:10 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
So my proposal would be:
wal_mode=crash/archive/standby
archive_mode=on/off
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 23, 2010 at 6:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Agreed on the general point, but AFAICS that proposal keeps the meaning
of archive_mode the same as it was.
Well, clearly it doesn't. Someone who thinks they can simply turn
On Fri, Apr 23, 2010 at 7:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 23, 2010 at 6:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Agreed on the general point, but AFAICS that proposal keeps the meaning
of archive_mode the same as it was.
Well,
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 23, 2010 at 7:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, there is another variable that they'll have to adjust as well,
but ISTM that archive_mode still does what it did before, ie, determine
whether we attempt to archive WAL segments.
On Fri, Apr 23, 2010 at 7:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 23, 2010 at 7:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, there is another variable that they'll have to adjust as well,
but ISTM that archive_mode still does what it
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 23, 2010 at 7:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think from the user's point of view it does what it did before.
The fact that the actual content of WAL changed was an implementation
detail that users weren't aware of. Now that we
On Fri, Apr 23, 2010 at 7:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 23, 2010 at 7:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think from the user's point of view it does what it did before.
The fact that the actual content of WAL changed
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 23, 2010 at 7:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I would expect that they'll get an error message that makes it clear
enough what to do ;-). In any case, changing the name is hardly going
to fix things so that 8.4 settings will
On Fri, Apr 23, 2010 at 8:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 23, 2010 at 7:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I would expect that they'll get an error message that makes it clear
enough what to do ;-). In any case, changing
On Fri, Apr 23, 2010 at 1:04 AM, Robert Haas robertmh...@gmail.com wrote:
One way we could fix this is use 2 bits rather than 1 for
XLogStandbyInfoMode. One bit could indicate that either
archive_mode=on or max_wal_senders0, and the second bit could
indicate that recovery_connections=on. If
59 matches
Mail list logo
