master in standby mode croaks
in [PgSql]
|
From: Robert Haas on 14 Apr 2010 07:07 On Wed, Apr 14, 2010 at 4:21 AM, Simon Riggs <simon(a)2ndquadrant.com> 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 > standby. There are many ways to screw up that ignore the manual, which > is why the manual exists. > > If you can show a full test case, with failure, then I'll follow it > through. Huh? If I had done everything correctly, of course I wouldn't have gotten an error message at all. Surely the point is that if I do something wrong, I should get an error message that describes what I actually did wrong rather than an error message telling me that I did something wrong which I clearly did not do. The recent patch to allow starting from a shutdown checkpoint means that a standby can be created by shutting down the master and taking a filesystem-level snapshot of the cluster directly, creating recovery.conf, and firing it up again. Anyone who does that with the default postgresql.conf, though, is going to get a message telling them that they need to change a setting which is already set correctly. ....Robert -- 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 14 Apr 2010 07:52 On Wed, 2010-04-14 at 07:07 -0400, Robert Haas wrote: > On Wed, Apr 14, 2010 at 4:21 AM, Simon Riggs <simon(a)2ndquadrant.com> 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 > > standby. There are many ways to screw up that ignore the manual, which > > is why the manual exists. > > > > If you can show a full test case, with failure, then I'll follow it > > through. > > Huh? If I had done everything correctly, of course I wouldn't have > gotten an error message at all. Surely the point is that if I do > something wrong, I should get an error message that describes what I > actually did wrong rather than an error message telling me that I did > something wrong which I clearly did not do. I will change the error message. > The recent patch to allow starting from a shutdown checkpoint means > that a standby can be created by shutting down the master and taking a > filesystem-level snapshot of the cluster directly, creating > recovery.conf, and firing it up again. Anyone who does that with the > default postgresql.conf, though, is going to get a message telling > them that they need to change a setting which is already set > correctly. Why would they do that? I would never claim this supports all use cases, just the sensible ones. -- 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: Robert Haas on 17 Apr 2010 17:44 On Wed, Apr 14, 2010 at 7:52 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > On Wed, 2010-04-14 at 07:07 -0400, Robert Haas wrote: >> On Wed, Apr 14, 2010 at 4:21 AM, Simon Riggs <simon(a)2ndquadrant.com> 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 >> > standby. There are many ways to screw up that ignore the manual, which >> > is why the manual exists. >> > >> > If you can show a full test case, with failure, then I'll follow it >> > through. >> >> Huh? If I had done everything correctly, of course I wouldn't have >> gotten an error message at all. Surely the point is that if I do >> something wrong, I should get an error message that describes what I >> actually did wrong rather than an error message telling me that I did >> something wrong which I clearly did not do. > > 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 sure what we should change it TO, given that the situation is the result of an interaction between three different GUCs and we have no way to distinguish which one(s) are the problem. ....Robert -- 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 17 Apr 2010 18:41 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 > sure what we should change it TO, given that the situation is the > result of an interaction between three different GUCs and we have no > way to distinguish which one(s) are the problem. "You need all three" covers it. -- 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: Robert Haas on 17 Apr 2010 18:52 On Sat, Apr 17, 2010 at 6:41 PM, Simon Riggs <simon(a)2ndquadrant.com> 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. So let's change the error message. Of course I'm not quite >> sure what we should change it TO, given that the situation is the >> result of an interaction between three different GUCs and we have no >> way to distinguish which one(s) are the problem. > > "You need all three" covers it. Actually you need standby_connections and either archive_mode=on or max_wal_senders>0, I think. ....Robert -- 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: mremap and bus error Next: [HACKERS] Compile fail, alpha5 & gcc 4.3.3 in elog.c |