On Wed, Apr 14, 2010 at 7:52 AM, Simon Riggs <simon@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@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