| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Sergei Kornilov <sk(at)zsrv(dot)org> |
| Cc: | "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: allow online change primary_conninfo |
| Date: | 2019-02-01 02:00:52 |
| Message-ID: | 20190201020052.GE2179@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jan 31, 2019 at 04:13:22PM +0300, Sergei Kornilov wrote:
> I my opinion this is not issue, database logs can have sensitive
> data. User queries, for example. If we not want expose such info -
> it is ok just hide new value from logs with new GUC flag? Or i need
> implement masked conninfo for this purpose?
You have problems with things in this area for any commands logged and
able to show a connection string or a password, which can go down as
well to CREATE/ALTER ROLE or FDWs. So for the purpose of what's
discussed on this thread it does not sound like a requirement to be
able to hide that. Role DDLs can take an already-hashed input to
avoid that, still knowing the MD5 hash is sufficient for connection
(not for SCRAM!). Now for FDWs..
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tsunakawa, Takayuki | 2019-02-01 02:05:51 | RE: reloption to prevent VACUUM from truncating empty pages at the end of relation |
| Previous Message | Michael Paquier | 2019-02-01 01:50:32 | Re: A few new options for vacuumdb |