Re: -O switch - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: -O switch
Date
Msg-id CABUevEzYuTTDem+dQMWtA1CUC0Ame6AR7WxdtEh4PZ05Tmj29Q@mail.gmail.com
Whole thread Raw
In response to Re: -O switch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: -O switch  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Anastasia Lubennikova
Date:
Subject: Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits
Next
From: Amit Langote
Date:
Subject: Re: ModifyTable overheads in generic plans