From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: -O switch |
Date: | 2020-11-04 01:10:45 |
Message-ID: | 1098378.1604452245@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Magnus Hagander <magnus(at)hagander(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2020-11-04 01:20:45 | Re: Collation versioning |
Previous Message | Kyotaro Horiguchi | 2020-11-04 01:09:28 | Re: Dereference before NULL check (src/backend/storage/ipc/latch.c) |