Should we really recommend "-A md5 or -A password"?

[Daniel Westermann (DWE)]

Hi,

I just came across this:
"Also, specify -A md5 or -A password so that the default trust authentication 
mode is not used;"
https://www.postgresql.org/docs/current/creating-cluster.html

Shouldn't we change that to "-A scram-sha-256" ?

Regards
Daniel

Re: Should we really recommend "-A md5 or -A password"?

[Magnus Hagander]

On Tue, May 31, 2022 at 2:29 PM Daniel Westermann (DWE) <
daniel.westerm...@dbi-services.com> wrote:

> Hi,
>
> I just came across this:
> "Also, specify -A md5 or -A password so that the default trust
> authentication mode is not used;"
> https://www.postgresql.org/docs/current/creating-cluster.html
>
> Shouldn't we change that to "-A scram-sha-256" ?
>

Yes I think we absolutely should!

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/ 

Re: Should we really recommend "-A md5 or -A password"?

[Jonathan S. Katz]

On 5/31/22 8:35 AM, Magnus Hagander wrote:



On Tue, May 31, 2022 at 2:29 PM Daniel Westermann (DWE) 
> wrote:


Hi,

I just came across this:
"Also, specify -A md5 or -A password so that the default trust
authentication mode is not used;"
https://www.postgresql.org/docs/current/creating-cluster.html


Shouldn't we change that to "-A scram-sha-256" ?


Yes I think we absolutely should!


+1

Proposed patch attached. This also removes "-A password" from that 
sentence as well.


Jonathan
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 62cec614d3..fac9b6b3bd 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -199,8 +199,8 @@ postgres$ initdb -D 
/usr/local/pgsql/data
  password
  of the superuser

-   Also, specify -A md5 or
-   -A password so that the default trust 
authentication
+   Also, specify -A scram-sha-256
+   so that the default trust authentication
mode is not used; or modify the generated pg_hba.conf
file after running initdb, but
before you start the server for the first time. (Other


OpenPGP_signature
Description: OpenPGP digital signature

Re: Should we really recommend "-A md5 or -A password"?

[Daniel Westermann (DWE)]

>> Yes I think we absolutely should!

>+1
>Proposed patch attached. This also removes "-A password" from that 
>sentence as well.

You've been faster than me :) 
Looks good.

Regards
Daniel

Can we still dump version 7?

[Daniel Westermann (DWE)]

Hi,

this commit (64f3524e2c8deebc02808aa5ebdfa17859473add) removed dump support for 
dumping from  pre-8.0. 

I guess this statement is not true anymore?
"Current releases of the dump programs can read data from any server version 
back to 7.0."
https://www.postgresql.org/docs/current/upgrading.html 

Regards
Daniel

Re: Can we still dump version 7?

[Tom Lane]

"Daniel Westermann (DWE)"  writes:
> I guess this statement is not true anymore?
> "Current releases of the dump programs can read data from any server version 
> back to 7.0."
> https://www.postgresql.org/docs/current/upgrading.html 

Ugh, missed that, thanks for spotting it.

I wonder whether we should update this or just remove it --- it's
clearly something that's likely to get missed again.

regards, tom lane

Re: Can we still dump version 7?

[Jonathan S. Katz]

On 5/31/22 10:55 AM, Tom Lane wrote:

"Daniel Westermann (DWE)"  writes:

I guess this statement is not true anymore?
"Current releases of the dump programs can read data from any server version back to 
7.0."
https://www.postgresql.org/docs/current/upgrading.html


Ugh, missed that, thanks for spotting it.

I wonder whether we should update this or just remove it --- it's
clearly something that's likely to get missed again.


While burdensome, +1 for updating. We don't want users to get caught by 
surprise if pg_dumpall does not work on an old version when trying to 
update to a newer version.


Jonathan


OpenPGP_signature
Description: OpenPGP digital signature

CREATE EXTENSION not adding extension on second SCHEMA

[PG Doc comments form]

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/14/sql-createextension.html
Description:

I'm trying to add an extension to two schemas that I have in my DB.

steps:

1)

CREATE EXTENSION unaccent with SCHEMA public;

response: OK.

2) 

CREATE EXTENSION unaccent with SCHEMA public_test;

response: SQL Error [42710]: ERROR: extension "unaccent" already exists

I tryed:

SET search_path = public_test;
CREATE EXTENSION unaccent;

 and the response is: response: SQL Error [42710]: ERROR: extension
"unaccent" already exists

Re: CREATE EXTENSION not adding extension on second SCHEMA

[jian he]

quote from manual:

> CREATE EXTENSION loads a new extension into the current database. There
> must not be an extension of the same name already loaded.
>

You can try to alter[1] the extension to make it located to another schema.

[1]: https://www.postgresql.org/docs/14/sql-alterextension.html


On Tue, May 31, 2022 at 8:39 PM PG Doc comments form 
wrote:

> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/14/sql-createextension.html
> Description:
>
> I'm trying to add an extension to two schemas that I have in my DB.
>
> steps:
>
> 1)
>
> CREATE EXTENSION unaccent with SCHEMA public;
>
> response: OK.
>
> 2)
>
> CREATE EXTENSION unaccent with SCHEMA public_test;
>
> response: SQL Error [42710]: ERROR: extension "unaccent" already exists
>
> I tryed:
>
> SET search_path = public_test;
> CREATE EXTENSION unaccent;
>
>  and the response is: response: SQL Error [42710]: ERROR: extension
> "unaccent" already exists
>


-- 
 I recommend David Deutsch's <>

  Jian

Re: CREATE EXTENSION not adding extension on second SCHEMA

[David G. Johnston]

On Tuesday, May 31, 2022, PG Doc comments form 
wrote:

> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/14/sql-createextension.html
> Description:
>
> I'm trying to add an extension to two schemas that I have in my DB.
>
> steps:
>
> 1)
>
> CREATE EXTENSION unaccent with SCHEMA public;
>
> response: OK.
>
> 2)
>
> CREATE EXTENSION unaccent with SCHEMA public_test;
>
> response: SQL Error [42710]: ERROR: extension "unaccent" already exists
>
> I tryed:
>
> SET search_path = public_test;
> CREATE EXTENSION unaccent;
>
>  and the response is: response: SQL Error [42710]: ERROR: extension
> "unaccent" already exists
>


It doesn’t work and isn’t documented as something that does work.  I really
don’t see a need to say you cannot install the same extension multiple
times explicitly - the self-describing error seems sufficient.

David J.

Fwd: Adding more detail to pg_upgrade documentation

[Nikhil Shetty]

Hi,

We are upgrading from Postgres 11 to 13. During upgrade we found that the
physical slots on the old cluster are not copied to the new cluster.

This information is not mentioned in the documentation -
https://www.postgresql.org/docs/13/pgupgrade.html

Just thought it would be good to have this detail

Thanks and Regards,
Nikhil

Re: CREATE EXTENSION not adding extension on second SCHEMA

[Tom Lane]

"David G. Johnston"  writes:
> On Tuesday, May 31, 2022, PG Doc comments form 
> wrote:
>> I'm trying to add an extension to two schemas that I have in my DB.

> It doesn’t work and isn’t documented as something that does work.  I really
> don’t see a need to say you cannot install the same extension multiple
> times explicitly - the self-describing error seems sufficient.

The CREATE EXTENSION reference page says

"There must not be an extension of the same name already loaded."

and later

"Remember that the extension itself is not considered to be within any
schema: extensions have unqualified names that must be unique
database-wide. But objects belonging to the extension can be within
schemas."

I hardly see how we could make this any plainer.

regards, tom lane

Re: Can we still dump version 7?

[Daniel Westermann (DWE)]

>> 
>> Ugh, missed that, thanks for spotting it.
>> I wonder whether we should update this or just remove it --- it's
>> clearly something that's likely to get missed again.

>While burdensome, +1 for updating. We don't want users to get caught by 
>surprise if pg_dumpall does not work on an old version when trying to 
>update to a newer version.

What about something like this:
"Current releases of the dump programs can read data from any supported version 
of PostgreSQL. You can expect the last XXX unsupported versions to work as 
well. If you cannot dump your version of PostgreSQL with the current releases 
you need to take an extra step and use a version of the dump programs which can 
still read from your old release."

That would remove the version number and there is no risk we miss it again in 
the future. I am not sure about the official policy for that, though.

Regards
Daniel

Re: Can we still dump version 7?

[Tom Lane]

"Jonathan S. Katz"  writes:
> On 5/31/22 10:55 AM, Tom Lane wrote:
>> I wonder whether we should update this or just remove it --- it's
>> clearly something that's likely to get missed again.

> While burdensome, +1 for updating. We don't want users to get caught by 
> surprise if pg_dumpall does not work on an old version when trying to 
> update to a newer version.

Further investigation shows that we've failed to update this twice in
the past six years, and failed to update a similar comment about psql
once.  I fixed 'em, but I have very little hope that they'll stay fixed.

regards, tom lane

Re: CREATE EXTENSION not adding extension on second SCHEMA

[Gustavo]

Thank you so much guys, my mistake I didn't pay attention. I'm new
to PostgreSQL and your help is much appreciated!



Em ter., 31 de mai. de 2022 às 12:32, Tom Lane  escreveu:

> "David G. Johnston"  writes:
> > On Tuesday, May 31, 2022, PG Doc comments form 
> > wrote:
> >> I'm trying to add an extension to two schemas that I have in my DB.
>
> > It doesn’t work and isn’t documented as something that does work.  I
> really
> > don’t see a need to say you cannot install the same extension multiple
> > times explicitly - the self-describing error seems sufficient.
>
> The CREATE EXTENSION reference page says
>
> "There must not be an extension of the same name already loaded."
>
> and later
>
> "Remember that the extension itself is not considered to be within any
> schema: extensions have unqualified names that must be unique
> database-wide. But objects belonging to the extension can be within
> schemas."
>
> I hardly see how we could make this any plainer.
>
> regards, tom lane
>

Re: Can we still dump version 7?

[Jonathan S. Katz]

On 5/31/22 12:21 PM, Tom Lane wrote:

"Jonathan S. Katz"  writes:

On 5/31/22 10:55 AM, Tom Lane wrote:

I wonder whether we should update this or just remove it --- it's
clearly something that's likely to get missed again.



While burdensome, +1 for updating. We don't want users to get caught by
surprise if pg_dumpall does not work on an old version when trying to
update to a newer version.


Further investigation shows that we've failed to update this twice in
the past six years, and failed to update a similar comment about psql
once.  I fixed 'em, but I have very little hope that they'll stay fixed.


Could we add as part of the branching procedure that we update this value?

Jonathan


OpenPGP_signature
Description: OpenPGP digital signature

Re: Should we really recommend "-A md5 or -A password"?

[Magnus Hagander]

On Tue, May 31, 2022 at 3:57 PM Jonathan S. Katz 
wrote:

> On 5/31/22 8:35 AM, Magnus Hagander wrote:
> >
> >
> > On Tue, May 31, 2022 at 2:29 PM Daniel Westermann (DWE)
> >  > > wrote:
> >
> > Hi,
> >
> > I just came across this:
> > "Also, specify -A md5 or -A password so that the default trust
> > authentication mode is not used;"
> > https://www.postgresql.org/docs/current/creating-cluster.html
> > 
> >
> > Shouldn't we change that to "-A scram-sha-256" ?
> >
> >
> > Yes I think we absolutely should!
>
> +1
>
> Proposed patch attached. This also removes "-A password" from that
> sentence as well.
>

Applied and backpatched to 14. Thanks!

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/