| From: | Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com> |
|---|---|
| To: | Magnus Hagander <magnus(at)hagander(dot)net> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: when the startup process doesn't |
| Date: | 2021-04-20 15:17:20 |
| Message-ID: | 20210420171720.56599607@firost |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 20 Apr 2021 15:04:28 +0200
Magnus Hagander <magnus(at)hagander(dot)net> wrote:
[...]
> Yeah, I think we should definitely limit this to local access, one way
> or another. Realistically using pg_hba is going to require catalog
> access, isn't it? And we can't just go ignore those rows in pg_hba
> that for example references role membership (as well as all those auth
> methods you can't use).
Two another options:
1. if this is limited to local access only, outside of the log entries, the
status of the startup could be updated in the controldata file as well. This
would allows to watch it without tail-grep'ing logs using eg. pg_controldata.
2. maybe the startup process could ignore update_process_title? As far
as I understand the doc correctly, this GUC is mostly useful for backends on
Windows.
Regards,
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Dilger | 2021-04-20 15:33:52 | Re: pg_amcheck option to install extension |
| Previous Message | Tom Lane | 2021-04-20 15:09:27 | Re: pg_amcheck option to install extension |