On Tue, Mar 09, 2021 at 05:45:56PM -0500, Tom Lane wrote:
> I have no objection to the backend-side changes, since we can be sure
> those won't affect people until they do a major-version upgrade to v14.
> But the situation is squishier on the client side, and I don't really
> see that pulling out
Michael Paquier writes:
> On Tue, Mar 09, 2021 at 10:58:21AM -0500, Tom Lane wrote:
>> In short, I think I'm a vote for reverting to the v13 behavior.
> The libpq part is a good point, as it could be annoying for people to
> get a changing behavior once the libpq version changes for anything
> us
On Tue, Mar 09, 2021 at 10:58:21AM -0500, Tom Lane wrote:
> I'm fairly distressed by this patch series, and this proposed change in
> particular, because it seems to be going in very much the wrong direction.
> The objective ought to be simplification, but you're doing exactly the
> opposite.
Yeah
> On 9 Mar 2021, at 16:58, Tom Lane wrote:
> In short, I think I'm a vote for reverting to the v13 behavior.
Ok, then let us just go ahead and do that.
--
Daniel Gustafsson https://vmware.com/
Daniel Gustafsson writes:
> Having tried a number of different ways to fix this I think the least
> intrusive
> fix is to teach pg_upgrade and dblink about sslcompression, like how've
> already
> taught it about other options. Building any infrastructure to handle
> deprecated options and exten
> On 9 Mar 2021, at 12:19, Michael Paquier wrote:
>
> On Tue, Mar 09, 2021 at 12:26:15PM +0900, Michael Paquier wrote:
>> It looks like it is not that much a good idea to define it as a debug
>> option after all. So I guess that the attached would fix the failure,
>> where FDW servers can still
On Tue, Mar 09, 2021 at 12:19:41PM +0100, Daniel Gustafsson wrote:
> While not pretty, I think that might be the least invasive option right now.
crake has turned back to green just now. Let's discuss that a bit
more, even if it does not feel like an issue we absolutely have to
address in this re
On Tue, Mar 09, 2021 at 12:26:15PM +0900, Michael Paquier wrote:
> It looks like it is not that much a good idea to define it as a debug
> option after all. So I guess that the attached would fix the failure,
> where FDW servers can still pass down the parameter at will for
> backward-compatibilit
> On 9 Mar 2021, at 04:26, Michael Paquier wrote:
> It looks like it is not that much a good idea to define it as a debug
> option after all. So I guess that the attached would fix the failure,
> where FDW servers can still pass down the parameter at will for
> backward-compatibility, and where
On Tue, Mar 09, 2021 at 02:18:52AM +, Michael Paquier wrote:
> Remove support for SSL compression
>
> PostgreSQL disabled compression as of e3bdb2d and the documentation
> recommends against using it since. Additionally, SSL compression has
> been disabled in OpenSSL since version 1.1.0, and
Remove support for SSL compression
PostgreSQL disabled compression as of e3bdb2d and the documentation
recommends against using it since. Additionally, SSL compression has
been disabled in OpenSSL since version 1.1.0, and was disabled in many
distributions long before that. The most recent TLS v
11 matches
Mail list logo
