Thread: -O switch
postgres --help: -o OPTIONS pass "OPTIONS" to each server process (obsolete) This was marked obsolete in 2006 (86c23a6eb28). Is it perhaps time to get rid of it? -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> postgres --help:
> -o OPTIONS pass "OPTIONS" to each server process (obsolete)
> This was marked obsolete in 2006 (86c23a6eb28).
I don't think it's really obsolete ... don't we use that to pass
PGOPTIONS through from the client?
regards, tom lane
On Thu, Oct 29, 2020 at 4:45 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Magnus Hagander <magnus@hagander.net> writes: > > postgres --help: > > -o OPTIONS pass "OPTIONS" to each server process (obsolete) > > > This was marked obsolete in 2006 (86c23a6eb28). > > I don't think it's really obsolete ... don't we use that to pass > PGOPTIONS through from the client? Then it probably shouldn't be labeled as obsolete :) That said, I don't think we do, or I'm misunderstanding what you mean. The startup packet which holds the client options is not read until we're already in the child process, so there is no further exec to be done? -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> On Thu, Oct 29, 2020 at 4:45 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I don't think it's really obsolete ... don't we use that to pass
>> PGOPTIONS through from the client?
> That said, I don't think we do, or I'm misunderstanding what you mean.
> The startup packet which holds the client options is not read until
> we're already in the child process, so there is no further exec to be
> done?
[ pokes around... ] Ah, you're right, that stuff goes through
port->cmdline_options now. It looks like the mechanism for -o
is the postmaster's ExtraOptions variable, which we could get
rid of this way. Seems like a reasonable thing, especially since
we unified all the other postmaster/postgres options already.
regards, tom lane
On Thu, Oct 29, 2020 at 5:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Magnus Hagander <magnus@hagander.net> writes: > > On Thu, Oct 29, 2020 at 4:45 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> I don't think it's really obsolete ... don't we use that to pass > >> PGOPTIONS through from the client? > > > That said, I don't think we do, or I'm misunderstanding what you mean. > > The startup packet which holds the client options is not read until > > we're already in the child process, so there is no further exec to be > > done? > > [ pokes around... ] Ah, you're right, that stuff goes through > port->cmdline_options now. It looks like the mechanism for -o > is the postmaster's ExtraOptions variable, which we could get > rid of this way. Seems like a reasonable thing, especially since > we unified all the other postmaster/postgres options already. PFA a patch to do this. Initially I kept the dynamic argv/argc in even though it's now hardcoded, in case we wanted to add something back. But given the way it looks now, perhaps we should just get rid of BackendRun() completely and directly call PostgresMain()? Or keep BackendRun() with just setting the TopMemoryContext, but removing the dynamic parts? -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Attachment
Magnus Hagander <magnus@hagander.net> writes:
> PFA a patch to do this.
One thing you missed is that the getopt() calls in both postmaster.c
and postgres.c have 'o:' entries that should be removed. Also IIRC
there is a "case 'o'" in postgres.c to go along with that.
> Initially I kept the dynamic argv/argc in even though it's now
> hardcoded, in case we wanted to add something back. But given the way
> it looks now, perhaps we should just get rid of BackendRun()
> completely and directly call PostgresMain()? Or keep BackendRun() with
> just setting the TopMemoryContext, but removing the dynamic parts?
I'd be inclined to keep it as-is for now. It's not adding any significant
amount of cycles compared to the process fork, so we might as well
preserve flexibility.
Is it really possible to not include miscadmin.h in postmaster.c?
I find that a bit surprising.
regards, tom lane
On Mon, Nov 2, 2020 at 6:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Magnus Hagander <magnus@hagander.net> writes: > > PFA a patch to do this. > > One thing you missed is that the getopt() calls in both postmaster.c > and postgres.c have 'o:' entries that should be removed. Also IIRC > there is a "case 'o'" in postgres.c to go along with that. Ha. Of course. Oops. PFA updated. > > Initially I kept the dynamic argv/argc in even though it's now > > hardcoded, in case we wanted to add something back. But given the way > > it looks now, perhaps we should just get rid of BackendRun() > > completely and directly call PostgresMain()? Or keep BackendRun() with > > just setting the TopMemoryContext, but removing the dynamic parts? > > I'd be inclined to keep it as-is for now. It's not adding any significant > amount of cycles compared to the process fork, so we might as well > preserve flexibility. > > Is it really possible to not include miscadmin.h in postmaster.c? > I find that a bit surprising. I did too, but having removed it postmaster.c still compiles fine without warnings for me. It did also pass the cfbot build step, but it might be that it'll eventually break down on some more different buildfarm animal. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Attachment
Magnus Hagander <magnus@hagander.net> writes:
> [ remove_option_o_2.patch ]
This seems committable to me now, although ...
> On Mon, Nov 2, 2020 at 6:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Magnus Hagander <magnus@hagander.net> writes:
>>> Initially I kept the dynamic argv/argc in even though it's now
>>> hardcoded, in case we wanted to add something back. But given the way
>>> it looks now, perhaps we should just get rid of BackendRun()
>>> completely and directly call PostgresMain()? Or keep BackendRun() with
>>> just setting the TopMemoryContext, but removing the dynamic parts?
>> I'd be inclined to keep it as-is for now. It's not adding any significant
>> amount of cycles compared to the process fork, so we might as well
>> preserve flexibility.
... looking at this again, BackendRun certainly looks ridiculously
over-engineered for what it still does. If we keep it like this, we
should at least add a comment along the lines of "We once had the
ability to pass additional arguments to PostgresMain, and may someday
want to do that again". But I wouldn't object to getting rid of the
dynamic construction of the arg array, and the debug output too.
regards, tom lane
On Wed, Nov 4, 2020 at 2:10 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Magnus Hagander <magnus@hagander.net> writes: > > [ remove_option_o_2.patch ] > > This seems committable to me now, although ... > > > On Mon, Nov 2, 2020 at 6:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Magnus Hagander <magnus@hagander.net> writes: > >>> Initially I kept the dynamic argv/argc in even though it's now > >>> hardcoded, in case we wanted to add something back. But given the way > >>> it looks now, perhaps we should just get rid of BackendRun() > >>> completely and directly call PostgresMain()? Or keep BackendRun() with > >>> just setting the TopMemoryContext, but removing the dynamic parts? > > >> I'd be inclined to keep it as-is for now. It's not adding any significant > >> amount of cycles compared to the process fork, so we might as well > >> preserve flexibility. > > ... looking at this again, BackendRun certainly looks ridiculously > over-engineered for what it still does. If we keep it like this, we > should at least add a comment along the lines of "We once had the > ability to pass additional arguments to PostgresMain, and may someday > want to do that again". But I wouldn't object to getting rid of the > dynamic construction of the arg array, and the debug output too. Yeah, looking at it again, I agree. PFA an updated patch, which I'll go ahead and push shortly. I do noticed when looking through this -- the comment before the function says: * returns: * Shouldn't return at all. * If PostgresMain() fails, return status. I'm pretty sure that's incorrect in the current branches as well, since it's a void function it will never return anything. Pretty sure it should just have the first point and not the second one there, or is this trying to convey some meaning I'm just not getting? -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Attachment
Magnus Hagander <magnus@hagander.net> writes:
> On Wed, Nov 4, 2020 at 2:10 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ... looking at this again, BackendRun certainly looks ridiculously
>> over-engineered for what it still does.
> Yeah, looking at it again, I agree. PFA an updated patch, which I'll
> go ahead and push shortly.
LGTM.
> I do noticed when looking through this -- the comment before the function says:
> * returns:
> * Shouldn't return at all.
> * If PostgresMain() fails, return status.
> I'm pretty sure that's incorrect in the current branches as well,
> since it's a void function it will never return anything. Pretty sure
> it should just have the first point and not the second one there, or
> is this trying to convey some meaning I'm just not getting?
Looking at old versions, BackendRun and PostgresMain used to be
declared to return int. Whoever changed that to void evidently
missed updating this comment.
I'd reduce the whole thing to "Doesn't return." If you were feeling
really ambitious you could start plastering pg_attribute_noreturn() on
these functions ... but since that would be placed on the declarations,
a comment here would still be in order probably.
regards, tom lane
On Mon, Nov 9, 2020 at 4:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Magnus Hagander <magnus@hagander.net> writes: > > On Wed, Nov 4, 2020 at 2:10 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> ... looking at this again, BackendRun certainly looks ridiculously > >> over-engineered for what it still does. > > > Yeah, looking at it again, I agree. PFA an updated patch, which I'll > > go ahead and push shortly. > > LGTM. Pushed. > > I do noticed when looking through this -- the comment before the function says: > > > * returns: > > * Shouldn't return at all. > > * If PostgresMain() fails, return status. > > > I'm pretty sure that's incorrect in the current branches as well, > > since it's a void function it will never return anything. Pretty sure > > it should just have the first point and not the second one there, or > > is this trying to convey some meaning I'm just not getting? > > Looking at old versions, BackendRun and PostgresMain used to be > declared to return int. Whoever changed that to void evidently > missed updating this comment. > > I'd reduce the whole thing to "Doesn't return." If you were feeling > really ambitious you could start plastering pg_attribute_noreturn() on > these functions ... but since that would be placed on the declarations, > a comment here would still be in order probably. They're already marked pg_attribute_noreturn() in the declarations. It's just the comment that was a bit out of date. I'll go fix that one. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/