From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | alain radix <alain(dot)radix(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Requesting external_pid_file with postgres -C when not initialized lead to coredump |
Date: | 2016-06-22 15:24:59 |
Message-ID: | 31275.1466609099@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
alain radix <alain(dot)radix(at)gmail(dot)com> writes:
> Here is a new patch with postmaster.c modification so that it check about a
> empty string instead of a null pointer.
Why should we adopt this, when there is already a better (more complete)
fix in git?
I'm not sold on the wisdom of modifying the semantics of
external_pid_file, which is what this patch effectively does. I don't
know if anything outside our core code looks at that variable, but if
anything does, this would create issues for it.
I'm even less sold on the wisdom of changing every other GUC that
has a null bootstrap default, which is what we would also have to do
in order to avoid the identical misbehavior for other -C cases.
> The meaning is no more to avoid a core dump as you've done a change for
> that but to have the same result with postgres -C as with a request to
> pg_settings, an empty string when the parameter is not set.
Well, maybe we should make -C print an empty string not "(nil)" for
such cases. You're right that we don't make a distinction between
NULL and "" in other code paths that display a string GUC, so doing
so here is a bit inconsistent.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Rui Hai Jiang | 2016-06-22 15:52:04 | how is the WAL receiver process stopped and restarted when the network connection is broken and then restored? |
Previous Message | Robert Haas | 2016-06-22 15:18:20 | Re: Hash Indexes |