On 27.01.23 15:48, Peter Eisentraut wrote:
Btw., something that I have had in my notes for a while, but with this
it would now be officially exposed: Not all options can be safely set
during bootstrap. For example,
initdb -D data -c track_commit_timestamp=on
will fail an assertion.
Andres Freund writes:
> This commit unfortunately broke --wal-segsize. If I use a slightly larger than
> the default setting, I get:
> initdb --wal-segsize 64 somepath
> running bootstrap script ... 2023-03-22 13:06:41.282 PDT [639848] FATAL:
> "min_wal_size" must be at least twice
Hi,
This commit unfortunately broke --wal-segsize. If I use a slightly larger than
the default setting, I get:
initdb --wal-segsize 64 somepath
running bootstrap script ... 2023-03-22 13:06:41.282 PDT [639848] FATAL:
"min_wal_size" must be at least twice "wal_segment_size"
Greetings,
Andres
I wrote:
> Peter Eisentraut writes:
>> I would remove the
>> #if DEF_PGPORT != 5432
>> This was in the previous code too, but now if we remove it, then we
>> don't have any more hardcoded 5432 left, which seems like a nice
>> improvement in cleanliness.
> Hm. That'll waste a few cycles during
Peter Eisentraut writes:
> This patch looks good to me. It's a very nice simplification of the
> initdb.c code, even without the new feature.
Thanks for looking!
> I found that the addition of
> #include
> didn't appear to be necessary. Maybe it was required before
>
On 27.01.23 21:02, Tom Lane wrote:
I wrote:
Anyway, it seems like I gotta work harder. I'll produce a
new patch.
The string-hacking was fully as tedious as I expected. However, the
output looks pretty nice, and this does have the advantage that the
pre-programmed substitutions become a lot
On Fri, Jan 27, 2023 at 3:02 PM Tom Lane wrote:
> The string-hacking was fully as tedious as I expected. However, the
> output looks pretty nice, and this does have the advantage that the
> pre-programmed substitutions become a lot more robust: they are no
> longer dependent on the initdb code
I wrote:
>>> Anyway, it seems like I gotta work harder. I'll produce a
>>> new patch.
The string-hacking was fully as tedious as I expected. However, the
output looks pretty nice, and this does have the advantage that the
pre-programmed substitutions become a lot more robust: they are no
longer
"David G. Johnston" writes:
> On Fri, Jan 27, 2023 at 8:53 AM Tom Lane wrote:
>> Anyway, it seems like I gotta work harder. I'll produce a
>> new patch.
> How about just adding a "section" to the end of the file as needed:
> # AdHoc Settings Specified During InitDB
> max_connections=75
> ...
On Fri, Jan 27, 2023 at 8:53 AM Tom Lane wrote:
> Robert Haas writes:
> > The idea is that instead of:
>
> > replace_token(conflines, "#max_connections = 100", repltok);
>
> > You'd write something like:
>
> > replace_guc_value(conflines, "max_connections", repltok);
>
> > Which would look for
Robert Haas writes:
> The idea is that instead of:
> replace_token(conflines, "#max_connections = 100", repltok);
> You'd write something like:
> replace_guc_value(conflines, "max_connections", repltok);
> Which would look for a line matching /^#max_connections\s+=\s/, and
> then identify
On Fri, Jan 27, 2023 at 10:34 AM Tom Lane wrote:
> One idea if we want to make it work like that could be to stop
> trying to edit out the default value, and instead make the file
> contents look like, say,
>
> #huge_pages = try # on, off, or try
> huge_pages = off
Peter Eisentraut writes:
> On 25.01.23 22:25, Tom Lane wrote:
>> The specified settings
>> are applied on the command line of the initial probe calls
>> (which happen before we've made any config files), and then they
>> are added to postgresql.auto.conf, which causes them to take
>> effect for
On Wed, Jan 25, 2023 at 4:26 PM Tom Lane wrote:
> So this invents an initdb switch "-c NAME=VALUE" just like the
> one that the server itself has long had.
HUGE +1 from me. This will, I think, be extremely convenient in many situations.
> The specified settings
> are applied on the command line
On Fri, 27 Jan 2023 at 09:49, Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 25.01.23 22:25, Tom Lane wrote:
> > So this invents an initdb switch "-c NAME=VALUE" just like the
> > one that the server itself has long had.
>
> This seems useful.
>
> > The specified settings
> >
On 25.01.23 22:25, Tom Lane wrote:
So this invents an initdb switch "-c NAME=VALUE" just like the
one that the server itself has long had.
This seems useful.
The specified settings
are applied on the command line of the initial probe calls
(which happen before we've made any config files),
Andres Freund writes:
> On 2023-01-25 16:25:19 -0500, Tom Lane wrote:
>> The attached patch responds to the discussion at [1] about how
>> we ought to offer a way to set any server GUC from the initdb
>> command line.
> Are you thinking of backpatching this, to offer the people affected by the
>
Hi,
On 2023-01-25 16:25:19 -0500, Tom Lane wrote:
> The attached patch responds to the discussion at [1] about how
> we ought to offer a way to set any server GUC from the initdb
> command line.
Are you thinking of backpatching this, to offer the people affected by the
issue in [1] a way out?
The attached patch responds to the discussion at [1] about how
we ought to offer a way to set any server GUC from the initdb
command line. Currently, if for some reason the server won't
start with default parameters, the only way to get through initdb
is to change the installed version of
19 matches
Mail list logo
