Re: Changing shared_buffers without restart - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: Changing shared_buffers without restart
Date
Msg-id CAExHW5uUONOHs3SC+0onpgDJXVHKqX=x1cJ7MKKrHxa2c1VK2Q@mail.gmail.com
Whole thread Raw
In response to Re: Changing shared_buffers without restart  (Dmitry Dolgov <9erthalion6@gmail.com>)
Responses Re: Changing shared_buffers without restart
List pgsql-hackers
On Wed, Apr 9, 2025 at 1:15 PM Dmitry Dolgov <9erthalion6@gmail.com> wrote:
>
> > On Wed, Apr 09, 2025 at 11:12:18AM GMT, Ashutosh Bapat wrote:
> > On Mon, Apr 7, 2025 at 2:13 PM Dmitry Dolgov <9erthalion6@gmail.com> wrote:
> > >
> > > In the new v4 version
> > > of the patch the first option is implemented.
> > >
> >
> > The patches don't apply cleanly using git am but patch -p1 applies
> > them cleanly. However I see following compilation errors
> > RuntimeError: command "ninja" failed with error
>
> Becase it's relatively meaningless to apply a patch to the tip of the
> master around the release freeze time :) Commit 65c298f61fc has
> introduced new usage of GetHugePageSize, which was modified in my patch.
> I'm going to address it with the next rebased version, in the meantime
> you can always use the specified base commit to apply the changeset:
>
>     base-commit: 5e1915439085014140314979c4dd5e23bd677cac

There is a higher chance that people will try these patches now than
it was two days before and more chance if they find the patches
applicable easily.

../../coderoot/pg/src/include/storage/s_lock.h:93:2: error: #error
"s_lock.h may not be included from frontend code"

How about this? Why is that happening?

--
Best Wishes,
Ashutosh Bapat



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: sync_standbys_defined read/write race on startup
Next
From: Andrei Lepikhov
Date:
Subject: Re: Memoize ANTI and SEMI JOIN inner