Postgres 11 release notes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
253 messages Options
1234567 ... 13
Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Bruce Momjian
On Tue, May 15, 2018 at 06:40:18AM +0000, Huong Dangminh wrote:

> Hi,
>
> > From: David Rowley [mailto:[hidden email]]
> > Sent: Tuesday, May 15, 2018 3:01 PM
> > To: Bruce Momjian <[hidden email]>
> > Cc: Đặng Minh Hướng <[hidden email]>; PostgreSQL-development
> > <[hidden email]>
> > Subject: Re: Postgres 11 release notes
> >
> > On 15 May 2018 at 08:28, Bruce Momjian <[hidden email]> wrote:
> > >         Consistently return <literal>NaN</literal> for
> > >         <literal>NaN</literal> inputs to <function>power()</literal>
> > >         on older platforms (Dang Minh Huong)
> >
> > While I'm not in favour of removing Dang's credit here, technically this
> > patch was Tom's. The code added in float.c by Dang's patch
> > (61b200e2f) was effectively reverted by 6bdf1303.  Dang's regression tests
> > remain, so should also be credited along with Tom.
>
> Thanks David, I agreed.
> Also 6bdf1303 should be included like below,
>
> <!--
>  Branch: master [6bdf1303b] Avoid wrong results for power() with NaN
> +Branch: master [61b200e2f] Avoid wrong results for power() with NaN
>  -->
>  
>         <para>
>          Consistently return <literal>NaN</literal> for
>          <literal>NaN</literal> inputs to <function>power()</function>
> -        on older platforms (Dang Minh Huong)
> +        on older platforms (Tom Lane, Dang Minh Huong)
>         </para>

OK, changed, thanks.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Bruce Momjian
In reply to this post by Etsuro Fujita
On Tue, May 15, 2018 at 02:26:33PM +0900, Etsuro Fujita wrote:

> (2018/05/12 0:08), Bruce Momjian wrote:
> >I have committed the first draft of the Postgres 11 release notes.  I
> >will add more markup soon.  You can view the most current version here:
> >
> > http://momjian.us/pgsql_docs/release-11.html
> >
> >I expect a torrent of feedback.  ;-)
> >
> >On a personal note, I want to apologize for not adequately championing
> >two features that I think have strategic significance but didn't make it
> >into Postgres 11:  parallel FDW access and improved multi-variate
> >statistics.  I hope to do better job during Postgres 12.
>
> Thanks for compiling this, Bruce!
>
> I found a copy-pasto in this:
>
>     Below you will find a detailed account of the changes between
>     <productname>PostgreSQL</productname> 10 and the previous major
>     release.
>
> I think the PG version should be 11, not 10.  Patch attached.

Ah, seems I missed that one, thanks.

---------------------------------------------------------------------------


>
> Best regards,
> Etsuro Fujita

> diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
> index 4b31b46..407c67b 100644
> --- a/doc/src/sgml/release-11.sgml
> +++ b/doc/src/sgml/release-11.sgml
> @@ -345,7 +345,7 @@ Branch: master [6bdf1303b] Avoid wrong results for power() with NaN
>  
>     <para>
>      Below you will find a detailed account of the changes between
> -    <productname>PostgreSQL</productname> 10 and the previous major
> +    <productname>PostgreSQL</productname> 11 and the previous major
>      release.
>     </para>
>  


--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Bruce Momjian
In reply to this post by akapila
On Tue, May 15, 2018 at 01:04:55PM +0530, Amit Kapila wrote:

> On Tue, May 15, 2018 at 11:43 AM, David Rowley
> <[hidden email]> wrote:
> > On 12 May 2018 at 03:08, Bruce Momjian <[hidden email]> wrote:
> >> I have committed the first draft of the Postgres 11 release notes.  I
> >> will add more markup soon.  You can view the most current version here:
> >>
> >>         http://momjian.us/pgsql_docs/release-11.html
> >>
> >> I expect a torrent of feedback.  ;-)
> >
> > I wonder if 3cda10f41bfed -- "Use atomic ops to hand out pages to scan
> > in parallel scan." should be listed in the notes.
> >
> > If so, I'd suggest something like:
> >
> > Improve performance of Parallel Seq Scans with many parallel workers
> > (David Rowley).
> >
>
> +1 to add this in Release Notes.

Done, and URL updated with all confirmed changed.  :-)

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Tatsuo Ishii-3
In reply to this post by Bruce Momjian
>> This commit gives user-visible changes to the statment timeout
>> behavior. So I think this should be added to the release notes.
>
> OK, makes sense. Here is what I added:
>
> 2017-09-18 [f8e5f156b] Rearm statement_timeout after each executed query.
>
>         In the <link linkend="protocol-query-concepts">Extended Query
>         Protocol</link>, have <varname>statement_timeout</varname> apply
>         to each <literal>Execute</literal> message, not to all commands
>         before <literal>Sync</literal> (Tatsuo Ishii)

Can you please add Andres Freund to the author? He made extensive
changes to the original patch to improve it.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

Reply | Threaded
Open this post in threaded view
|

NaNs in numeric_power (was Re: Postgres 11 release notes)

Tom Lane-2
In reply to this post by David Rowley-3
David Rowley <[hidden email]> writes:
> On 16 May 2018 at 02:01, Tom Lane <[hidden email]> wrote:
>> I'm not particularly fussed about getting credit for that.  However,
>> looking again at how that patch series turned out --- ie, that
>> we ensured POSIX behavior for NaNs only in HEAD --- I wonder
>> whether we shouldn't do what was mentioned in the commit log for
>> 6bdf1303, and teach numeric_pow() about these same special cases.
>> It seems like it would be more consistent to change both functions
>> for v11, rather than letting that other shoe drop in some future
>> major release.

> I'm inclined to agree. It's hard to imagine these two functions
> behaving differently in regards to NaN input is useful to anyone.

Here's a proposed patch for that.

                        regards, tom lane


diff --git a/src/backend/utils/adt/numeric.c b/src/backend/utils/adt/numeric.c
index dcf31e3..8dfdffc 100644
*** a/src/backend/utils/adt/numeric.c
--- b/src/backend/utils/adt/numeric.c
*************** numeric_power(PG_FUNCTION_ARGS)
*** 2972,2981 ****
  NumericVar result;
 
  /*
! * Handle NaN
  */
! if (NUMERIC_IS_NAN(num1) || NUMERIC_IS_NAN(num2))
  PG_RETURN_NUMERIC(make_result(&const_nan));
 
  /*
  * Initialize things
--- 2972,2998 ----
  NumericVar result;
 
  /*
! * Handle NaN cases.  We follow the POSIX spec for pow(3), which says that
! * NaN ^ 0 = 1, and 1 ^ NaN = 1, while all other cases with NaN inputs
! * yield NaN (with no error).
  */
! if (NUMERIC_IS_NAN(num1))
! {
! if (!NUMERIC_IS_NAN(num2))
! {
! init_var_from_num(num2, &arg2);
! if (cmp_var(&arg2, &const_zero) == 0)
! PG_RETURN_NUMERIC(make_result(&const_one));
! }
! PG_RETURN_NUMERIC(make_result(&const_nan));
! }
! if (NUMERIC_IS_NAN(num2))
! {
! init_var_from_num(num1, &arg1);
! if (cmp_var(&arg1, &const_one) == 0)
! PG_RETURN_NUMERIC(make_result(&const_one));
  PG_RETURN_NUMERIC(make_result(&const_nan));
+ }
 
  /*
  * Initialize things
diff --git a/src/test/regress/expected/numeric.out b/src/test/regress/expected/numeric.out
index 17985e8..1cb3c3b 100644
*** a/src/test/regress/expected/numeric.out
--- b/src/test/regress/expected/numeric.out
*************** select 0.0 ^ 12.34;
*** 1664,1669 ****
--- 1664,1700 ----
   0.0000000000000000
  (1 row)
 
+ -- NaNs
+ select 'NaN'::numeric ^ 'NaN'::numeric;
+  ?column?
+ ----------
+       NaN
+ (1 row)
+
+ select 'NaN'::numeric ^ 0;
+  ?column?
+ ----------
+         1
+ (1 row)
+
+ select 'NaN'::numeric ^ 1;
+  ?column?
+ ----------
+       NaN
+ (1 row)
+
+ select 0 ^ 'NaN'::numeric;
+  ?column?
+ ----------
+       NaN
+ (1 row)
+
+ select 1 ^ 'NaN'::numeric;
+  ?column?
+ ----------
+         1
+ (1 row)
+
  -- invalid inputs
  select 0.0 ^ (-12.34);
  ERROR:  zero raised to a negative power is undefined
diff --git a/src/test/regress/sql/numeric.sql b/src/test/regress/sql/numeric.sql
index d77504e..a939412 100644
*** a/src/test/regress/sql/numeric.sql
--- b/src/test/regress/sql/numeric.sql
*************** select (-12.34) ^ 0.0;
*** 911,916 ****
--- 911,923 ----
  select 12.34 ^ 0.0;
  select 0.0 ^ 12.34;
 
+ -- NaNs
+ select 'NaN'::numeric ^ 'NaN'::numeric;
+ select 'NaN'::numeric ^ 0;
+ select 'NaN'::numeric ^ 1;
+ select 0 ^ 'NaN'::numeric;
+ select 1 ^ 'NaN'::numeric;
+
  -- invalid inputs
  select 0.0 ^ (-12.34);
  select (-12.34) ^ 1.2;
Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Bruce Momjian
In reply to this post by Tatsuo Ishii-3
fOn Wed, May 16, 2018 at 06:11:52AM +0900, Tatsuo Ishii wrote:

> >> This commit gives user-visible changes to the statment timeout
> >> behavior. So I think this should be added to the release notes.
> >
> > OK, makes sense. Here is what I added:
> >
> > 2017-09-18 [f8e5f156b] Rearm statement_timeout after each executed query.
> >
> >         In the <link linkend="protocol-query-concepts">Extended Query
> >         Protocol</link>, have <varname>statement_timeout</varname> apply
> >         to each <literal>Execute</literal> message, not to all commands
> >         before <literal>Sync</literal> (Tatsuo Ishii)
>
> Can you please add Andres Freund to the author? He made extensive
> changes to the original patch to improve it.

Done.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Tatsuo Ishii-3
>> Can you please add Andres Freund to the author? He made extensive
>> changes to the original patch to improve it.
>
> Done.

Thanks!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Tatsuo Ishii-3
In reply to this post by Bruce Momjian
> Change the ps process display labels to match the
> pg_stat_activity.backend_type labels (Peter Eisentraut)

pg_stat_activity.backend_type label for postgres process dedicated to
user sessions is "client backend" while ps still shows something like
"postgres: t-ishii postgres [local] idle". Do we want to mention this?

For example "Change the ps process display labels to match the
pg_stat_activity.backend_type labels except client backend (Peter
Eisentraut)"

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Bruce Momjian
On Wed, May 16, 2018 at 08:33:53AM +0900, Tatsuo Ishii wrote:

> > Change the ps process display labels to match the
> > pg_stat_activity.backend_type labels (Peter Eisentraut)
>
> pg_stat_activity.backend_type label for postgres process dedicated to
> user sessions is "client backend" while ps still shows something like
> "postgres: t-ishii postgres [local] idle". Do we want to mention this?
>
> For example "Change the ps process display labels to match the
> pg_stat_activity.backend_type labels except client backend (Peter
> Eisentraut)"

Good point.  Should we mention background workers instead?

        Change the ps process display labels for background workers
        to match the pg_stat_activity.backend_type labels Eisentraut)

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Tatsuo Ishii-3
>> pg_stat_activity.backend_type label for postgres process dedicated to
>> user sessions is "client backend" while ps still shows something like
>> "postgres: t-ishii postgres [local] idle". Do we want to mention this?
>>
>> For example "Change the ps process display labels to match the
>> pg_stat_activity.backend_type labels except client backend (Peter
>> Eisentraut)"
>
> Good point.  Should we mention background workers instead?
>
> Change the ps process display labels for background workers
> to match the pg_stat_activity.backend_type labels Eisentraut)

Seems good to me.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Bruce Momjian
On Wed, May 16, 2018 at 08:52:05AM +0900, Tatsuo Ishii wrote:

> >> pg_stat_activity.backend_type label for postgres process dedicated to
> >> user sessions is "client backend" while ps still shows something like
> >> "postgres: t-ishii postgres [local] idle". Do we want to mention this?
> >>
> >> For example "Change the ps process display labels to match the
> >> pg_stat_activity.backend_type labels except client backend (Peter
> >> Eisentraut)"
> >
> > Good point.  Should we mention background workers instead?
> >
> > Change the ps process display labels for background workers
> > to match the pg_stat_activity.backend_type labels Eisentraut)
>
> Seems good to me.

Done.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Tatsuo Ishii-3
In reply to this post by Bruce Momjian
There's a small typo.

> Add support for with huge(large) pages on Windows (Takayuki Tsunakawa, Thomas Munro)

I think a space between "huge" and "(large)" is needed.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Bruce Momjian
On Wed, May 16, 2018 at 09:01:35AM +0900, Tatsuo Ishii wrote:
> There's a small typo.
>
> > Add support for with huge(large) pages on Windows (Takayuki Tsunakawa, Thomas Munro)
>
> I think a space between "huge" and "(large)" is needed.

Done, URL updated.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Michael Paquier-2
In reply to this post by Bruce Momjian
On Mon, May 14, 2018 at 08:45:44PM -0400, Bruce Momjian wrote:
> What TLS does is to mix the offered ciphers into the negotiation hash so
> a man-in-the-middle can't pretend it doesn't support something.  Could
> we do something like that here?

I have to admit that I don't quite follow here, the shape of channel
binding data is decided by RFC 5929, so we need to stick with it.

> I have to question the value of man-in-the-middle protection that is so
> easily bypassed.

Well, the backend does its job, and answers based on what the client
wants to do.  But what you are questioning here is the handling of
authentication downgrade attempts from a server by libpq, which is a
different problem, larger than just channel binding as it relates as
well to MD5/SCRAM interactions.  For example, it is perfectly possible
to implement downgrade protections for any drivers which speak the
protocol, like JDBC, even with a v11 backend.
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

akapila
In reply to this post by Bruce Momjian
On Wed, May 16, 2018 at 12:17 AM, Bruce Momjian <[hidden email]> wrote:

> On Tue, May 15, 2018 at 08:45:07AM +0530, Amit Kapila wrote:
>> No, it is not like that.  We divide the scan among workers and each
>> worker should perform projection of the rows it scanned (after
>> applying filter).  Now, if the expensive functions are part of target
>> lists, then we can push the computation of expensive functions (as
>> part of target list) in workers which will divide the work.
>>
>> >  Really?  Do
>> > we run each column in its own worker or do we split the result set into
>> > parts and run those in parallel?  How do we know, just the function call
>> > costs?
>> >
>>
>> The function's cost can be determined via pg_proc->procost.  For this
>> particular case, you can refer the call graph -
>> create_pathtarget->set_pathtarget_cost_width->cost_qual_eval_node->cost_qual_eval_walker->get_func_cost
>>
>> >  I can admit I never saw that coming.
>> >
>>
>> I think the use case becomes interesting with parallel query because
>> now you can divide such cost among workers.
>>
>> Feel free to ask more questions if above doesn't clarify the usage of
>> these features.
>
> OK, I have added the following release note item for both of these:
>
> 2017-11-16 [e89a71fb4] Pass InitPlan values to workers via Gather (Merge).
> 2018-03-29 [3f90ec859] Postpone generate_gather_paths for topmost scan/join rel
> 2018-03-29 [11cf92f6e] Rewrite the code that applies scan/join targets to paths
>
>         Allow single-evaluation queries, e.g. <literal>FROM</literal>
>         clause queries, and functions in the target list to be
>         parallelized (Amit Kapila, Robert Haas)
>

Sorry, but it is not clear to me what you intend to say by "e.g.
<literal>FROM</literal> clause queries"?   What I could imagine is
something like "e.g. queries in <literal>WHERE</literal> clause that
return aggregate value"

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Reply | Threaded
Open this post in threaded view
|

Re: NaNs in numeric_power (was Re: Postgres 11 release notes)

Dean Rasheed-3
In reply to this post by Tom Lane-2
On 15 May 2018 at 22:55, Tom Lane <[hidden email]> wrote:

> David Rowley <[hidden email]> writes:
>> On 16 May 2018 at 02:01, Tom Lane <[hidden email]> wrote:
>>> I'm not particularly fussed about getting credit for that.  However,
>>> looking again at how that patch series turned out --- ie, that
>>> we ensured POSIX behavior for NaNs only in HEAD --- I wonder
>>> whether we shouldn't do what was mentioned in the commit log for
>>> 6bdf1303, and teach numeric_pow() about these same special cases.
>>> It seems like it would be more consistent to change both functions
>>> for v11, rather than letting that other shoe drop in some future
>>> major release.
>
>> I'm inclined to agree. It's hard to imagine these two functions
>> behaving differently in regards to NaN input is useful to anyone.
>
> Here's a proposed patch for that.
>

In the case 1 ^ NaN = 1, what should the result scale be?

For other inputs, the result scale is at least as large as the scale
of the first input, so I would suggest that the same ought to be the
case here.

Otherwise, this looks fine, and I agree that it makes thinks neater /
more consistent.

Regards,
Dean

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Etsuro Fujita
In reply to this post by Bruce Momjian
(2018/05/16 4:45), Bruce Momjian wrote:

> On Tue, May 15, 2018 at 02:26:33PM +0900, Etsuro Fujita wrote:
>> (2018/05/12 0:08), Bruce Momjian wrote:
>>> I have committed the first draft of the Postgres 11 release notes.  I
>>> will add more markup soon.  You can view the most current version here:
>>>
>>> http://momjian.us/pgsql_docs/release-11.html
>>>
>>> I expect a torrent of feedback.  ;-)
>>>
>>> On a personal note, I want to apologize for not adequately championing
>>> two features that I think have strategic significance but didn't make it
>>> into Postgres 11:  parallel FDW access and improved multi-variate
>>> statistics.  I hope to do better job during Postgres 12.
>>
>> Thanks for compiling this, Bruce!
>>
>> I found a copy-pasto in this:
>>
>>      Below you will find a detailed account of the changes between
>>      <productname>PostgreSQL</productname>  10 and the previous major
>>      release.
>>
>> I think the PG version should be 11, not 10.  Patch attached.
>
> Ah, seems I missed that one, thanks.

Thank you.

Best regards,
Etsuro Fujita

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Heikki Linnakangas
In reply to this post by Michael Paquier-2
On 16/05/18 07:22, Michael Paquier wrote:

> On Mon, May 14, 2018 at 08:45:44PM -0400, Bruce Momjian wrote:
>> What TLS does is to mix the offered ciphers into the negotiation hash so
>> a man-in-the-middle can't pretend it doesn't support something.  Could
>> we do something like that here?
>
> I have to admit that I don't quite follow here, the shape of channel
> binding data is decided by RFC 5929, so we need to stick with it.
>
>> I have to question the value of man-in-the-middle protection that is so
>> easily bypassed.
>
> Well, the backend does its job, and answers based on what the client
> wants to do.  But what you are questioning here is the handling of
> authentication downgrade attempts from a server by libpq, which is a
> different problem, larger than just channel binding as it relates as
> well to MD5/SCRAM interactions.  For example, it is perfectly possible
> to implement downgrade protections for any drivers which speak the
> protocol, like JDBC, even with a v11 backend.

I have to agree with Bruce, that it's pretty useless to implement
channel binding, if there is no way to require it in libpq. IMHO that
must be fixed.

It's true that even if libpq doesn't implement it, other drivers like
JDBC could. Good for them, but that still sucks for libpq.

- Heikki

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Heikki Linnakangas
In reply to this post by Bruce Momjian
> * Allow bytes to be specified for server variable sizes (Beena Emerson)
>
> The specification is "B".

I had to dig the commit in the git history to figure out what this is.
I'd suggest rewording this:

* Allow server options related to memory and file sizes, to be specified
as number of bytes.

The new unit is "B". This is in addition to "kB", "MB", "GB" and "TB",
which were accepted previously.

- Heikki

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Michael Paquier-2
In reply to this post by Heikki Linnakangas
On Wed, May 16, 2018 at 01:09:07PM +0300, Heikki Linnakangas wrote:
> I have to agree with Bruce, that it's pretty useless to implement channel
> binding, if there is no way to require it in libpq. IMHO that must be
> fixed.

Wouldn't we want to also do something for the case where a client is
willing to use SCRAM but that the server forces back MD5?  In which
case, one possibility is a connection parameter like the following,
named say authmethod:
- An empty value is equivalent to the current behavior, and is the
default.
- 'scram' means that client is willing to use SCRAM, which would cause a
failure if server attempts to enforce MD5.
- 'scram-plus' means that client enforces SCRAM and channel binding.

Or we could just have a channel_binding_mode, which has a "require"
value like sslmode, and "prefer" mode, which is the default and the
current behavior...  Still what to do with MD5 requests in this case?
--
Michael

signature.asc (849 bytes) Download Attachment
1234567 ... 13