On Wed, May 17, 2017 at 12:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Yeah, you have a point. I'm willing to admit that we may have defined
>> the behavior of the feature incorrectly, provided that you're willing
>> to admit that you're proposing a definition change, not just a bug
>> fix.
>
>> Anybody else want to weigh in with an opinion here?
>
> I'm not really on board with "try each server until you find one where
> this dbname+username+password combination works". That's just a recipe
> for trouble, especially the password angle.
Sure, I know what *your* opinion is. And I'm somewhat inclined to
agree, but not to the degree that I don't think we should hear what
other people have to say.
> I suggest that we need to conditionalize the decision based on what
> SQLSTATE is reported. Not sure offhand if it's better to have a whitelist
> of SQLSTATEs that allow failing over to the next server, or a blacklist of
> SQLSTATEs that don't.
Urgh. There are two things I don't like about that. First, it's a
major redesign of this feature at the 11th hour. Second, if we can't
even agree on the general question of whether all, some, or no server
errors should cause a retry, the chances of agreeing on which SQL
states to include in the retry loop are probably pretty low. Indeed,
there might not be one answer that will be right for everyone.
One good argument for leaving this alone entirely is that this feature
was committed on November 3rd and this thread began on May 12th. If
there was ample time before feature freeze to question the design and
nobody did, then I'm not sure why we should disregard the freeze to
start whacking it around now, especially on the strength of one
complaint. It may be that after we get some field experience with
this the right thing to do will become clearer.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
