| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Thomas Munro <munro(at)ip9(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Cluster name in ps output |
| Date: | 2014-05-05 15:36:20 |
| Message-ID: | 20140505153620.GA27783@awork2.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2014-05-05 09:52:33 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> >>> Aren't you potentially dereferencing a NULL pointer here?
>
> >> Hmm -- I thought the GUC machinery would make sure cluster_name either
> >> pointed to the default I provided, an empty string, or a string read from
> >> the configuration file. Perhaps I need to go and read up on how GUCs work.
>
> > That's true - but I am not sure you can guarantee it's only called after
> > the GUC machinery has started up.
>
> The elog code MUST be able to work before GUC initialization is done.
> What do you think will happen if we fail to open postgresql.conf,
> for example?
But elog. shouldn't call init_ps_display(), right? Anyway, I am all for
initializing it sensibly, after all it was I that suggested doing so above...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2014-05-05 15:37:53 | Re: Cluster name in ps output |
| Previous Message | David G Johnston | 2014-05-05 15:35:16 | Re: Supporting multiple column assignment in UPDATE (9.5 project) |