From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: Daniel Gustafsson <daniel@yesql.se>,
        Postgres hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Improve errors when setting incorrect bounds for SSL protocols
In-reply-to: <20200118033620.GC230692@paquier.xyz>
References: <20200114035420.GE1515@paquier.xyz>
 <E51AB0A2-2282-446E-B88B-055900259BFE@yesql.se>
 <20200115022805.GB2243@paquier.xyz>
 <BF02E97A-850A-46CF-9197-4834C3ED4C67@yesql.se>
 <20200116010052.GA3117@paquier.xyz> <20200118033620.GC230692@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Sat, 18 Jan 2020 12:36:20 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <27573.1581015893.1@sss.pgh.pa.us>
Date: Thu, 06 Feb 2020 14:04:53 -0500
Message-ID: <27574.1581015893@sss.pgh.pa.us>
Precedence: bulk

Michael Paquier <michael@paquier.xyz> writes:
> On Thu, Jan 16, 2020 at 10:00:52AM +0900, Michael Paquier wrote:
>> Thanks for the review.  Let's wait a couple of days to see if others
>> have objections or more comments about this patch, but I'd like to
>> fix the issue and backpatch down to 12 where the parameters have been
>> introduced.

> And committed.

I just happened to look at this patch while working on the release notes.
I think this is a bad idea and very probably creates worse problems than
it fixes.  As we have learned painfully in the past, you can't have GUC
check or assign hooks that look at other GUC variables, because that
creates order-of-operations problems.  If a postgresql.conf update is
trying to change both values (hardly an unlikely scenario, for this
pair of variables) then the checks are going to be comparing against the
old values of the other variables, leading to either incorrect rejections
of valid states or incorrect acceptances of invalid states.  It's pure
accident that the particular cases tested in the regression tests behave
sanely.

I think this should be reverted.  Perhaps there's a way to do it without
these problems, but we failed to find one in the past.

			regards, tom lane