Deprecating plans for PGPASSWORD environment variable as insecure

[Alexey Murz Korepov]

MySQL in version have deprecated the `MYSQL_PWD` environment variable,
because they considers this way as insecure, quote from
https://dev.mysql.com/doc/refman/8.0/en/environment-variables.html#idm45429554761920
:

>  Use of MYSQL_PWD to specify a MySQL password must be considered
extremely insecure and should not be used. Some versions of ps include an
option to display the environment of running processes. On some systems, if
you set MYSQL_PWD, your password is exposed to any other user who runs ps.
Even on systems without such a version of ps, it is unwise to assume that
there are no other methods by which users can examine process environments.

So I want to ask - is there the same plan for PostgreSQL with it's
`PGPASSWORD` environment variable for future versions, or will it stay as
non-deprecated for future versions, and we can continue to use it without
worrying?

-- 
Best regards,
Alexey Murz Korepov.
E-mail: mur...@gmail.com
Messengers: Matrix - https://matrix.to/#/@murz:ru-matrix.org Telegram -
@MurzNN

Re: Deprecating plans for PGPASSWORD environment variable as insecure

[Pavel Stehule]

Hi

po 27. 12. 2021 v 9:55 odesílatel Alexey Murz Korepov 
napsal:

> MySQL in version have deprecated the `MYSQL_PWD` environment variable,
> because they considers this way as insecure, quote from
> https://dev.mysql.com/doc/refman/8.0/en/environment-variables.html#idm45429554761920
> :
>
> >  Use of MYSQL_PWD to specify a MySQL password must be considered
> extremely insecure and should not be used. Some versions of ps include an
> option to display the environment of running processes. On some systems, if
> you set MYSQL_PWD, your password is exposed to any other user who runs ps.
> Even on systems without such a version of ps, it is unwise to assume that
> there are no other methods by which users can examine process environments.
>
> So I want to ask - is there the same plan for PostgreSQL with it's
> `PGPASSWORD` environment variable for future versions, or will it stay as
> non-deprecated for future versions, and we can continue to use it without
> worrying?
>

 I don't remember any discussion about it. In the documentation is note, so
this way is not preferred

PGPASSWORD behaves the same as the password

connection parameter. Use of this environment variable is not recommended
for security reasons, as some operating systems allow non-root users to see
process environment variables via ps; instead consider using a password
file (see Section 34.16
).

https://www.postgresql.org/docs/current/libpq-envars.html

Regards

Pavel


> --
> Best regards,
> Alexey Murz Korepov.
> E-mail: mur...@gmail.com
> Messengers: Matrix - https://matrix.to/#/@murz:ru-matrix.org Telegram -
> @MurzNN
>

Logical Replication - One table 8 minutes, Identical Two Tables 28 Minutes (Expected 16 Minutes)

[Avi Weinberg]

Hi All,

When I have only one table (2.5GB) in logical replication publication it takes 
8 minutes to sync to the subscriber when I created a copy of the table and 
added it to the publication it took 28 minutes.  When I sync three IDENTICAL 
tables of the same size it take 46 minutes!
I expected the tables to be synched in parallel or at least one after the 
other, but it turned out the time increase is much larger than just to sync 
additional table of the same size.  Two tables should be 8*2=16 minutes and not 
28 and three tables should be 8*3=24 minutes and not 46.

The table has one pk int column and one binary column file_content of type 
bytea.

What might be the reason for this behavior? Can I improve the time it takes to 
sync several tables so it will be no more than the (time to sync one table) * 
(number of tables)

Doing it for two tables took 28 minutes
2021-12-27 10:32:13.740 UTC [4430] LOG:  logical replication apply worker for 
subscription "sub_gwn1" has started
2021-12-27 10:32:13.815 UTC [4431] LOG:  logical replication table 
synchronization worker for subscription "sub_gwn1", table "p1" has started
2021-12-27 10:32:13.827 UTC [4432] LOG:  logical replication table 
synchronization worker for subscription "sub_gwn1", table "p" has started
2021-12-27 10:57:57.542 UTC [4432] LOG:  logical replication table 
synchronization worker for subscription "sub_gwn1", table "p" has finished
2021-12-27 11:00:03.806 UTC [4431] LOG:  logical replication table 
synchronization worker for subscription "sub_gwn1", table "p1" has finished

Doing it for three tables took 46 minutes
2021-12-27 11:49:11.931 UTC [4739] LOG:  logical replication table 
synchronization worker for subscription "sub_gwn1", table "p2" has started
2021-12-27 11:49:11.948 UTC [4740] LOG:  logical replication table 
synchronization worker for subscription "sub_gwn1", table "p1" has started
2021-12-27 12:23:44.673 UTC [4740] LOG:  logical replication table 
synchronization worker for subscription "sub_gwn1", table "p1" has finished
2021-12-27 12:23:44.783 UTC [4845] LOG:  logical replication table 
synchronization worker for subscription "sub_gwn1", table "p" has started
2021-12-27 12:28:53.320 UTC [4739] LOG:  logical replication table 
synchronization worker for subscription "sub_gwn1", table "p2" has finished
2021-12-27 12:35:49.156 UTC [4845] LOG:  logical replication table 
synchronization worker for subscription "sub_gwn1", table "p" has finished

Thanks!

IMPORTANT - This email and any attachments is intended for the above named 
addressee(s), and may contain information which is confidential or privileged. 
If you are not the intended recipient, please inform the sender immediately and 
delete this email: you should not copy or use this e-mail for any purpose nor 
disclose its contents to any person.