Horton

Thread

Commits

  1. Remove -o option to postmaster

  1. -O switch

    Magnus Hagander <magnus@hagander.net> — 2020-10-29T14:41:48Z

    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/

  2. Re: -O switch

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-10-29T15:45:31Z

    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

  3. Re: -O switch

    Magnus Hagander <magnus@hagander.net> — 2020-10-29T16:03:01Z

    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/

  4. Re: -O switch

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-10-29T16:25:12Z

    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

  5. Re: -O switch

    Magnus Hagander <magnus@hagander.net> — 2020-11-02T13:46:02Z

    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/

  6. Re: -O switch

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-11-02T17:58:00Z

    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

  7. Re: -O switch

    Magnus Hagander <magnus@hagander.net> — 2020-11-03T09:38:39Z

    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/

  8. Re: -O switch

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-11-04T01:10:45Z

    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

  9. Re: -O switch

    Magnus Hagander <magnus@hagander.net> — 2020-11-09T10:42:02Z

    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/

  10. Re: -O switch

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-11-09T15:58:27Z

    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

  11. Re: -O switch

    Magnus Hagander <magnus@hagander.net> — 2020-11-10T12:12:49Z

    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/