On Mon, Apr 26, 2010 at 2:15 PM, Josh Berkus 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 list (pgsql-hackers
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 (pgsql-
On Mon, Apr 26, 2010 at 10:23 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
>> 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
>>> level
Robert Haas writes:
> On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
> 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, instead of having different modes that are somehow mutu
On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
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 a patch implementing
Robert Haas wrote:
On Fri, Apr 23, 2010 at 4:11 PM, Tom Lane wrote:
Robert Haas 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 d
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
On Fri, Apr 23, 2010 at 4:11 PM, Tom Lane wrote:
> Robert Haas 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
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
On Fri, Apr 23, 2010 at 8:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 23, 2010 at 7:28 PM, Tom Lane 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
Robert Haas writes:
> On Fri, Apr 23, 2010 at 7:28 PM, Tom Lane 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 still work, so why are you
>> giving
On Fri, Apr 23, 2010 at 7:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 23, 2010 at 7:12 PM, Tom Lane 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
Robert Haas writes:
> On Fri, Apr 23, 2010 at 7:12 PM, Tom Lane 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 have two interacting
>> features
On Fri, Apr 23, 2010 at 7:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 23, 2010 at 7:07 PM, Tom Lane 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 t
Robert Haas writes:
> On Fri, Apr 23, 2010 at 7:07 PM, Tom Lane 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.
> But it doesn't do EVERYTHING
On Fri, Apr 23, 2010 at 7:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 23, 2010 at 6:30 PM, Tom Lane 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 c
Robert Haas writes:
> On Fri, Apr 23, 2010 at 6:30 PM, Tom Lane 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
> archive_mode=on and set archive_command
On Fri, Apr 23, 2010 at 6:30 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 23, 2010 at 4:10 PM, Heikki Linnakangas
>> wrote:
>>> So my proposal would be:
>>>
>>> wal_mode=crash/archive/standby
>>> archive_mode=on/off # if on, wal_mode must be >= 'archive'
>>> archive_comma
Simon Riggs 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 the archiver *and whe
Simon Riggs 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 unarchived
segments to
Robert Haas writes:
> On Fri, Apr 23, 2010 at 4:10 PM, Heikki Linnakangas
> 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= # if > 0, wal_mode
On Fri, 2010-04-23 at 17:43 -0400, Robert Haas wrote:
> On Fri, Apr 23, 2010 at 4:10 PM, Heikki Linnakangas
> 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_
On Fri, Apr 23, 2010 at 4:10 PM, Heikki Linnakangas
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= # if > 0, wal_mode must be >= 'archive'
As a gener
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 sca
On Fri, 2010-04-23 at 16:50 -0400, Tom Lane wrote:
> Simon Riggs 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
> t
On Fri, Apr 23, 2010 at 4:50 PM, Tom Lane wrote:
> Simon Riggs 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 ord
Simon Riggs 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 wit
Simon Riggs 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 like "cra
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
Robert Haas 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.
> But we might be able
Tom Lane wrote:
> Robert Haas 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 l
On Fri, 2010-04-23 at 14:56 -0500, Kevin Grittner wrote:
> Simon Riggs 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
> want
On Fri, Apr 23, 2010 at 3:34 PM, Tom Lane wrote:
> Robert Haas 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
Simon Riggs 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 little time on
Simon Riggs 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
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 thi
Robert Haas 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
Simon Riggs 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 now, namely a GUC tha
On Fri, Apr 23, 2010 at 3:11 PM, Simon Riggs 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 options and I wan
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 to
On Fri, Apr 23, 2010 at 2:43 PM, Kevin Grittner
wrote:
> Tom Lane 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, bu
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 do
Tom Lane 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
> support HS?
On Fri, Apr 23, 2010 at 2:36 PM, Tom Lane wrote:
> Heikki Linnakangas 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 tha
Heikki Linnakangas 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 Standby, I think we'll come t
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_connect
Robert Haas writes:
> On Fri, Apr 23, 2010 at 12:09 PM, Tom Lane 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 clearly talking about two diffe
On Fri, Apr 23, 2010 at 12:09 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 23, 2010 at 7:12 AM, Heikki Linnakangas
>> 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
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:
http:/
Robert Haas writes:
> On Fri, Apr 23, 2010 at 7:12 AM, Heikki Linnakangas
> 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 folly
to set the assumption in stone by choosing a us
On Fri, Apr 23, 2010 at 8:54 PM, Robert Haas wrote:
> On Fri, Apr 23, 2010 at 7:40 AM, Heikki Linnakangas
> 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 t
On Fri, Apr 23, 2010 at 7:40 AM, Heikki Linnakangas
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 the
> system easier to explain. But
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_senders>0. If it's set to 'archi
Robert Haas wrote:
> On Fri, Apr 23, 2010 at 7:12 AM, Heikki Linnakangas
> wrote:
>> Robert Haas wrote:
>>> On Fri, Apr 23, 2010 at 5:24 AM, Heikki Linnakangas
>>> wrote:
I quite liked Robert's proposal to add an explicit GUC to control what
extra information is logged
(http://arch
On Fri, Apr 23, 2010 at 7:12 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> On Fri, Apr 23, 2010 at 5:24 AM, Heikki Linnakangas
>> wrote:
>>> I quite liked Robert's proposal to add an explicit GUC to control what
>>> extra information is logged
>>> (http://archives.postgresql.org/pgsql-hac
Robert Haas wrote:
> On Fri, Apr 23, 2010 at 5:24 AM, Heikki Linnakangas
> 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
On Fri, Apr 23, 2010 at 5:24 AM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> On Fri, Apr 23, 2010 at 1:04 AM, Robert Haas 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_senders>
Fujii Masao wrote:
> On Fri, Apr 23, 2010 at 1:04 AM, Robert Haas 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_senders>0, and the second bit could
>> indicate that recovery_connections=
On Fri, Apr 23, 2010 at 1:04 AM, Robert Haas 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_senders>0, and the second bit could
> indicate that recovery_connections=on. If the second bit is
On Sat, Apr 17, 2010 at 6:52 PM, Robert Haas wrote:
> On Sat, Apr 17, 2010 at 6:41 PM, Simon Riggs wrote:
>> On Sat, 2010-04-17 at 17:44 -0400, Robert Haas wrote:
>>
>>> > I will change the error message.
>>>
>>> I gave a good deal of thought to trying to figure out a cleaner
>>> solution to this
On Mon, Apr 19, 2010 at 5:31 AM, Fujii Masao wrote:
> On Mon, Apr 19, 2010 at 11:04 AM, Robert Haas wrote:
>>> First of all, I wonder why the latter two need to affect the decision of
>>> whether additional information is written to WAL for HS. How about just
>>> removing XLogIsNeeded() condition
On Mon, Apr 19, 2010 at 11:04 AM, Robert Haas wrote:
>> First of all, I wonder why the latter two need to affect the decision of
>> whether additional information is written to WAL for HS. How about just
>> removing XLogIsNeeded() condition from XLogStandbyInfoActive()?
>
> Bad idea, I think. If
On Sun, Apr 18, 2010 at 9:58 PM, Fujii Masao wrote:
> On Sun, Apr 18, 2010 at 7:52 AM, Robert Haas wrote:
>> On Sat, Apr 17, 2010 at 6:41 PM, Simon Riggs wrote:
>>> On Sat, 2010-04-17 at 17:44 -0400, Robert Haas wrote:
>>>
> I will change the error message.
I gave a good deal of t
On Sun, Apr 18, 2010 at 7:52 AM, Robert Haas wrote:
> On Sat, Apr 17, 2010 at 6:41 PM, Simon Riggs wrote:
>> On Sat, 2010-04-17 at 17:44 -0400, Robert Haas wrote:
>>
>>> > I will change the error message.
>>>
>>> I gave a good deal of thought to trying to figure out a cleaner
>>> solution to this
On Sat, Apr 17, 2010 at 6:41 PM, Simon Riggs wrote:
> On Sat, 2010-04-17 at 17:44 -0400, Robert Haas wrote:
>
>> > I will change the error message.
>>
>> I gave a good deal of thought to trying to figure out a cleaner
>> solution to this problem than just changing the error message and
>> failed.
On Sat, 2010-04-17 at 17:44 -0400, Robert Haas wrote:
> > I will change the error message.
>
> I gave a good deal of thought to trying to figure out a cleaner
> solution to this problem than just changing the error message and
> failed. So let's change the error message. Of course I'm not quite
On Wed, Apr 14, 2010 at 7:52 AM, Simon Riggs wrote:
> On Wed, 2010-04-14 at 07:07 -0400, Robert Haas wrote:
>> On Wed, Apr 14, 2010 at 4:21 AM, Simon Riggs wrote:
>> > On Sat, 2010-04-10 at 09:02 -0400, Robert Haas wrote:
>> >
>> >> So this can fail in either of two ways
>> >
>> > If I understand
On Wed, 2010-04-14 at 07:07 -0400, Robert Haas wrote:
> On Wed, Apr 14, 2010 at 4:21 AM, Simon Riggs wrote:
> > On Sat, 2010-04-10 at 09:02 -0400, Robert Haas wrote:
> >
> >> So this can fail in either of two ways
> >
> > If I understand this correctly, it is unconvincing as a failure mode
> > sin
On Wed, Apr 14, 2010 at 4:21 AM, Simon Riggs wrote:
> On Sat, 2010-04-10 at 09:02 -0400, Robert Haas wrote:
>
>> So this can fail in either of two ways
>
> If I understand this correctly, it is unconvincing as a failure mode
> since it doesn't follow any of the documented procedures for creating a
On Sat, 2010-04-10 at 09:02 -0400, Robert Haas wrote:
> So this can fail in either of two ways
If I understand this correctly, it is unconvincing as a failure mode
since it doesn't follow any of the documented procedures for creating a
standby. There are many ways to screw up that ignore the manu
On Fri, Apr 2, 2010 at 5:36 AM, Simon Riggs wrote:
> I can't duplicate this error based upon what you have said.
I fooled around with this some more and I think I know what's going
on. The error message I received was:
recovery connections cannot start because the recovery_connections
parameter
On Fri, 2010-04-02 at 04:51 -0400, Robert Haas wrote:
> On Apr 1, 2010, at 7:06 PM, Simon Riggs wrote:
> > On Tue, 2010-03-30 at 22:40 -0400, Robert Haas wrote:
> >> I discovered tonight that if you shut down a server, create
> >> recovery.conf with standby_mode = 'on', and start it back up again,
On Apr 1, 2010, at 7:06 PM, Simon Riggs wrote:
> On Tue, 2010-03-30 at 22:40 -0400, Robert Haas wrote:
>> I discovered tonight that if you shut down a server, create
>> recovery.conf with standby_mode = 'on', and start it back up again,
>> you get this:
>>
>> LOG: database system was shut down at
On Tue, 2010-03-30 at 22:40 -0400, Robert Haas wrote:
> I discovered tonight that if you shut down a server, create
> recovery.conf with standby_mode = 'on', and start it back up again,
> you get this:
>
> LOG: database system was shut down at 2010-03-30 22:34:09 EDT
> LOG: entering standby mode
I discovered tonight that if you shut down a server, create
recovery.conf with standby_mode = 'on', and start it back up again,
you get this:
LOG: database system was shut down at 2010-03-30 22:34:09 EDT
LOG: entering standby mode
FATAL: recovery connections cannot start because the
recovery_co
75 matches
Mail list logo
