On Fri, Jun 23, 2023 at 01:57:51PM +0900, Michael Paquier wrote:
> I could not resist adding two checks in the TAP tests to make sure
> that we don't report unknown. Perhaps that's not necessary, but that
> would provide coverage in a more broader way, and these are cheap.
>
> I have run one
On Tue, Jun 20, 2023 at 06:44:20PM -0500, Justin Pryzby wrote:
> On Tue, Jun 13, 2023 at 02:50:30PM +0900, Michael Paquier wrote:
>> On Mon, Jun 12, 2023 at 02:37:15PM -0700, Nathan Bossart wrote:
>> > Fair enough. I know I've been waffling in the GUC versus function
>> > discussion, but FWIW v7
On Tue, Jun 13, 2023 at 02:50:30PM +0900, Michael Paquier wrote:
> On Mon, Jun 12, 2023 at 02:37:15PM -0700, Nathan Bossart wrote:
> > Fair enough. I know I've been waffling in the GUC versus function
> > discussion, but FWIW v7 of the patch looks reasonable to me.
>
> +
On Tue, Jun 13, 2023 at 02:50:30PM +0900, Michael Paquier wrote:
> + Assert(strcmp("unknown", GetConfigOption("huge_pages_status", false,
> false)) != 0);
>
> Not sure that there is anything to gain with this assertion in
> CreateSharedMemoryAndSemaphores(), because this is pretty much
On Mon, Jun 12, 2023 at 11:11:14PM -0700, Nathan Bossart wrote:
> On Tue, Jun 13, 2023 at 02:50:30PM +0900, Michael Paquier wrote:
>> Don't we need to update save_backend_variables() and add an entry
>> in BackendParameters to make other processes launched by EXEC_BACKEND
>> inherit the status
On Tue, Jun 13, 2023 at 02:50:30PM +0900, Michael Paquier wrote:
> Don't we need to update save_backend_variables() and add an entry
> in BackendParameters to make other processes launched by EXEC_BACKEND
> inherit the status value set?
I thought this was handled by
On Mon, Jun 12, 2023 at 02:37:15PM -0700, Nathan Bossart wrote:
> Fair enough. I know I've been waffling in the GUC versus function
> discussion, but FWIW v7 of the patch looks reasonable to me.
+ Assert(strcmp("unknown", GetConfigOption("huge_pages_status", false,
false)) != 0);
Not
On Tue, May 02, 2023 at 11:17:50AM +0900, Michael Paquier wrote:
> On Thu, Apr 20, 2023 at 02:16:17PM -0700, Nathan Bossart wrote:
>> AFAICT this would involve adding a bool to BackendParameters and using it
>> in save_backend_variables() and restore_backend_variables(), which is an
>> additional
On Thu, Apr 20, 2023 at 02:16:17PM -0700, Nathan Bossart wrote:
> AFAICT this would involve adding a bool to BackendParameters and using it
> in save_backend_variables() and restore_backend_variables(), which is an
> additional 3 lines of code. That doesn't sound too bad to me, but perhaps
> I am
On Thu, Mar 23, 2023 at 07:23:28AM +0900, Michael Paquier wrote:
> On Wed, Mar 22, 2023 at 05:18:28PM -0500, Justin Pryzby wrote:
>> Wow, good point. I think to make it work we'd need put
>> huge_pages_active into BackendParameters and handle it in
>> save_backend_variables(). If so, that'd be
At Tue, 11 Apr 2023 15:17:46 +0900, Michael Paquier wrote
in
> On Thu, Mar 23, 2023 at 05:25:46PM +0900, Kyotaro Horiguchi wrote:
> > Wouldn't storing the value in the shared memory itself work? Though,
> > that space does become almost dead for the server's lifetime...
>
> Sure, it would
On Thu, Mar 23, 2023 at 05:25:46PM +0900, Kyotaro Horiguchi wrote:
> Wouldn't storing the value in the shared memory itself work? Though,
> that space does become almost dead for the server's lifetime...
Sure, it would work. However, we'd still need an interface for the
extra function. At this
On Tue, Mar 28, 2023 at 09:35:30AM +0900, Michael Paquier wrote:
> On Thu, Mar 23, 2023 at 08:50:50PM -0500, Justin Pryzby wrote:
>
> You mean that you abused of it in some custom branch running the CI on
> github? If I may ask, what did you do to make sure that huge pages
> are set when
On Tue, Mar 28, 2023 at 09:35:30AM +0900, Michael Paquier wrote:
> The patch needs to provide more details about the unknown state, IMO,
> to make it crystal-clear to the users what are the limitations of this
> GUC, especially regarding the fact that this is useful when "try"-ing
> to allocate
On Thu, Mar 23, 2023 at 08:50:50PM -0500, Justin Pryzby wrote:
> I'm sure it's possible, but it's also not worth writing a special
> implementation just to handle huge_pages_active, which is better written
> in 30 lines than in 300 lines.
>
> If we needed to avoid using a GUC, maybe it'd work to
On Thu, Mar 23, 2023 at 05:25:46PM +0900, Kyotaro Horiguchi wrote:
> Wouldn't storing the value in the shared memory itself work? Though,
> that space does become almost dead for the server's lifetime...
I'm sure it's possible, but it's also not worth writing a special
implementation just to
At Thu, 23 Mar 2023 07:23:28 +0900, Michael Paquier wrote
in
> On Wed, Mar 22, 2023 at 05:18:28PM -0500, Justin Pryzby wrote:
> > Wow, good point. I think to make it work we'd need put
> > huge_pages_active into BackendParameters and handle it in
> > save_backend_variables(). If so, that'd be
On Wed, Mar 22, 2023 at 05:18:28PM -0500, Justin Pryzby wrote:
> Wow, good point. I think to make it work we'd need put
> huge_pages_active into BackendParameters and handle it in
> save_backend_variables(). If so, that'd be strong argument for using a
> GUC, which already has all the necessary
On Wed, Mar 22, 2023 at 04:37:01PM +0900, Michael Paquier wrote:
> I have noted something.. For the WIN32 case, we have that:
>
> +++ b/src/backend/port/win32_shmem.c
> @@ -327,6 +327,8 @@ retry:
> Sleep(1000);
> continue;
> }
> +
> + huge_pages_active =
On Tue, Mar 21, 2023 at 09:19:41PM -0500, Justin Pryzby wrote:
> You set this patch to "waiting on author" twice. Would you let me know
> what I could do to help progress the patch? Right now, I have no idea.
My mistake, I've been looking at an incorrect version of the patch.
Thanks for
On Mon, Mar 20, 2023 at 02:03:13PM +0900, Michael Paquier wrote:
> On Mon, Mar 20, 2023 at 01:54:46PM +0900, Michael Paquier wrote:
> > The main advantage of a read-only GUC over a function is that users
> > would not need to start a postmaster to know if huge pages would be
> > active or not.
On Mon, Mar 20, 2023 at 01:09:09AM -0400, Tom Lane wrote:
> I'm confused here, because Horiguchi-san is saying that that
> won't work. I've not checked the code lately, but I think that
> "postgres -C var" prints its results before actually attempting
> to establish shared memory, so I suspect
Michael Paquier writes:
> On Tue, Mar 14, 2023 at 02:02:19PM +0900, Kyotaro Horiguchi wrote:
>> I slightly prefer using a function for this, as if GUC is used, it can
>> only return "unknown" for the command "postgres -C
>> huge_page_active". However, apart from this advantage, I prefer using
>>
On Mon, Mar 20, 2023 at 01:54:46PM +0900, Michael Paquier wrote:
> The main advantage of a read-only GUC over a function is that users
> would not need to start a postmaster to know if huge pages would be
> active or not. This is the main reason why a GUC would be a better
> fit, in my opinion,
On Tue, Mar 14, 2023 at 02:02:19PM +0900, Kyotaro Horiguchi wrote:
> Regarding huge_page_active, its value remains constant throughout a
> postmaster's lifespan. In this regard, GUC may be a better fit for
> this information. The issue with using GUC for this value is that the
> postgres command
At Mon, 13 Mar 2023 21:33:31 +0100, Stephen Frost wrote in
> > On Thu, Mar 09, 2023 at 03:02:29PM -0500, Stephen Frost wrote:
> > > * Justin Pryzby (pry...@telsasoft.com) wrote:
> > > Is there an agreement to use a function, instead ?
> >
> > Alvaro was -1 on using a function
>
>
> I don’t
Greetings,
On Mon, Mar 13, 2023 at 21:03 Justin Pryzby wrote:
> On Thu, Mar 09, 2023 at 03:02:29PM -0500, Stephen Frost wrote:
> > * Justin Pryzby (pry...@telsasoft.com) wrote:
> > > On Thu, Mar 09, 2023 at 09:34:10AM -0500, Stephen Frost wrote:
> > > > * Nathan Bossart
On Thu, Mar 09, 2023 at 03:02:29PM -0500, Stephen Frost wrote:
> * Justin Pryzby (pry...@telsasoft.com) wrote:
> > On Thu, Mar 09, 2023 at 09:34:10AM -0500, Stephen Frost wrote:
> > > * Nathan Bossart (nathandboss...@gmail.com) wrote:
> > > > On Wed, Feb 15, 2023 at 10:13:17AM -0800, Nathan
Greetings,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> On 2023-Mar-09, Justin Pryzby wrote:
> > On Thu, Mar 09, 2023 at 09:34:10AM -0500, Stephen Frost wrote:
> > > > +Reports whether huge pages are in use by the current instance.
> > > > +See for more information.
> > >
Greetings,
* Justin Pryzby (pry...@telsasoft.com) wrote:
> On Thu, Mar 09, 2023 at 09:34:10AM -0500, Stephen Frost wrote:
> > * Nathan Bossart (nathandboss...@gmail.com) wrote:
> > > On Wed, Feb 15, 2023 at 10:13:17AM -0800, Nathan Bossart wrote:
> > > > On Tue, Feb 14, 2023 at 07:32:56PM -0600,
On Thu, Mar 09, 2023 at 06:51:21PM +0100, Alvaro Herrera wrote:
> I'd rather make all these other places use "instance" instead. We used
> to consider these terms interchangeable, but since we introduced the
> glossary to unify the terminology, they are no longer supposed to be.
> A server (== a
On Thu, Mar 09, 2023 at 10:38:56AM -0600, Justin Pryzby wrote:
> On Thu, Mar 09, 2023 at 09:34:10AM -0500, Stephen Frost wrote:
>> To that end- perhaps this isn't appropriate as a GUC at all? Why not
>> have this just be a system information function? Functionally it really
>> provides the same
On 2023-Mar-09, Justin Pryzby wrote:
> On Thu, Mar 09, 2023 at 09:34:10AM -0500, Stephen Frost wrote:
> > > +Reports whether huge pages are in use by the current instance.
> > > +See for more information.
> > >
> > > I still think we should say "server" in place of "current
On Thu, Mar 09, 2023 at 09:34:10AM -0500, Stephen Frost wrote:
> Greetings,
>
> * Nathan Bossart (nathandboss...@gmail.com) wrote:
> > On Wed, Feb 15, 2023 at 10:13:17AM -0800, Nathan Bossart wrote:
> > > On Tue, Feb 14, 2023 at 07:32:56PM -0600, Justin Pryzby wrote:
> > >> On Mon, Feb 13, 2023
Greetings,
* Nathan Bossart (nathandboss...@gmail.com) wrote:
> On Wed, Feb 15, 2023 at 10:13:17AM -0800, Nathan Bossart wrote:
> > On Tue, Feb 14, 2023 at 07:32:56PM -0600, Justin Pryzby wrote:
> >> On Mon, Feb 13, 2023 at 08:18:52PM -0800, Nathan Bossart wrote:
> >>> I'm curious why you chose
On Wed, Feb 15, 2023 at 10:13:17AM -0800, Nathan Bossart wrote:
> On Tue, Feb 14, 2023 at 07:32:56PM -0600, Justin Pryzby wrote:
>> On Mon, Feb 13, 2023 at 08:18:52PM -0800, Nathan Bossart wrote:
>>> I'm curious why you chose to make this a string instead of an enum. There
>>> might be little
On Tue, Feb 14, 2023 at 07:32:56PM -0600, Justin Pryzby wrote:
> On Mon, Feb 13, 2023 at 08:18:52PM -0800, Nathan Bossart wrote:
>> On Mon, Feb 13, 2023 at 05:22:45PM -0600, Justin Pryzby wrote:
>> nitpick: Does this need to be initialized here?
>
> None of the GUCs' C vars need to be
On Mon, Feb 13, 2023 at 08:18:52PM -0800, Nathan Bossart wrote:
> On Mon, Feb 13, 2023 at 05:22:45PM -0600, Justin Pryzby wrote:
> > +Reports whether huge pages are in use by the current process.
> > +See for more information.
>
> nitpick: Should this say "server" instead of
On Mon, Feb 13, 2023 at 05:22:45PM -0600, Justin Pryzby wrote:
> +Reports whether huge pages are in use by the current process.
> +See for more information.
nitpick: Should this say "server" instead of "current process"?
> +static char *huge_pages_active = "unknown"; /*
On Thu, Feb 09, 2023 at 11:29:09AM -0800, Nathan Bossart wrote:
> On Thu, Feb 09, 2023 at 10:40:13AM +0100, Alvaro Herrera wrote:
> > On 2023-Feb-08, Justin Pryzby wrote:
> >> I don't think it makes sense to run postgres -C huge_pages_active,
> >> however, so I see no issue that that would always
On Thu, Feb 09, 2023 at 10:40:13AM +0100, Alvaro Herrera wrote:
> On 2023-Feb-08, Justin Pryzby wrote:
>> I don't think it makes sense to run postgres -C huge_pages_active,
>> however, so I see no issue that that would always returns "false".
>
> Hmm, I would initialize it to return "unknown"
On 2023-Feb-08, Justin Pryzby wrote:
> I don't think it makes sense to run postgres -C huge_pages_active,
> however, so I see no issue that that would always returns "false".
Hmm, I would initialize it to return "unknown" rather than "off" — and
make sure it turns "off" at the appropriate time.
On Thu, Feb 02, 2023 at 04:53:37PM +0100, Alvaro Herrera wrote:
> On 2023-Jan-24, Justin Pryzby wrote:
> > On Mon, Jan 23, 2023 at 05:33:35PM -0800, Andres Freund wrote:
> > > I'm ok with this being a GUC, it doesn't feel elegant, but I suspect
> > > there's
> > > no realistic elegant answer.
>
On Thu, Feb 02, 2023 at 04:53:37PM +0100, Alvaro Herrera wrote:
> Maybe I misread the code (actually I only read the patch), but -- does
> it set active=true when huge_pages=on? I think the code only works when
> huge_pages=try. That might be pretty confusing; I think it should say
> "on" in
On 2023-Jan-24, Justin Pryzby wrote:
> On Mon, Jan 23, 2023 at 05:33:35PM -0800, Andres Freund wrote:
> > I'm ok with this being a GUC, it doesn't feel elegant, but I suspect there's
> > no realistic elegant answer.
> Whether it's a GUC or a function, I propose to name it hugepages_active.
> If
On Tue, Jan 24, 2023 at 07:37:29PM -0600, Justin Pryzby wrote:
> BTW, I didn't realize it when I made the suggestion, nor when I wrote
> the patch, but a GUC was implemented in the v2 patch.
>
On Mon, Jan 23, 2023 at 05:33:35PM -0800, Andres Freund wrote:
> Hi,
>
> On 2023-01-23 19:21:00 -0600, Justin Pryzby wrote:
> > Michael seemed to support this idea and nobody verbalized hatred of it,
> > so I implemented it. In v15, we have shared_memory_size_in_huge_pages,
> > so this adds
Hi,
On 2023-01-23 19:21:00 -0600, Justin Pryzby wrote:
> Michael seemed to support this idea and nobody verbalized hatred of it,
> so I implemented it. In v15, we have shared_memory_size_in_huge_pages,
> so this adds effective_huge_pages.
>
> Feel free to suggest a better name.
Hm. Should this
On Wed, Nov 09, 2022 at 02:04:00PM +0900, Michael Paquier wrote:
> On Wed, Nov 09, 2022 at 11:47:57AM +0900, Kyotaro Horiguchi wrote:
> > Honestly I don't come up with other users of the new
> > log-level. Another possible issue is it might be a bit hard for people
> > to connect that level to
On Wed, Nov 09, 2022 at 11:47:57AM +0900, Kyotaro Horiguchi wrote:
> Honestly I don't come up with other users of the new
> log-level. Another possible issue is it might be a bit hard for people
> to connect that level to huge_pages=try, whereas I think we shouldn't
> put a description about the
At Tue, 8 Nov 2022 11:34:53 +1300, Thomas Munro wrote
in
> On Tue, Nov 8, 2022 at 4:56 AM Tom Lane wrote:
> > Andres Freund writes:
> > > On 2022-11-06 14:04:29 +0700, John Naylor wrote:
> > Agreed --- changing "on" to be exactly like "try" isn't an improvement.
> > If you want "try"
On Tue, Nov 8, 2022 at 4:56 AM Tom Lane wrote:
> Andres Freund writes:
> > On 2022-11-06 14:04:29 +0700, John Naylor wrote:
> >> I think the best thing to do is change huge_pages='on' to log a WARNING and
> >> fallback to regular pages if the mapping fails.
>
> > I am strongly opposed to making
Andres Freund writes:
> On 2022-11-06 14:04:29 +0700, John Naylor wrote:
>> I think the best thing to do is change huge_pages='on' to log a WARNING and
>> fallback to regular pages if the mapping fails.
> I am strongly opposed to making 'on' fall back to not using huge pages. That's
> what 'try'
Hi,
On 2022-11-06 14:04:29 +0700, John Naylor wrote:
> I think the best thing to do is change huge_pages='on' to log a WARNING and
> fallback to regular pages if the mapping fails. That way, both dev and prod
> can keep the same settings, since 'on' will have both visibility and
> robustness. I
On Sun, Nov 06, 2022 at 02:04:29PM +0700, John Naylor wrote:
> On Thu, Nov 3, 2022 at 8:11 AM Thomas Munro wrote:
> >
> > I wonder if the problem here is that people are reluctant to add noise
> > to every starting system. There are people who have not configured
> > their system and don't want
On Thu, Nov 3, 2022 at 8:11 AM Thomas Munro wrote:
>
> I wonder if the problem here is that people are reluctant to add noise
> to every starting system. There are people who have not configured
> their system and don't want to see that noise, and then some people
> have configured their system
; Julien Rouhaud ; Tom Lane
; Kyotaro Horiguchi
Subject: Re: Improve logging when using Huge Pages
On Wed, Aug 3, 2022 at 8:42 PM Shinoda, Noriyoshi (PN Japan FSIP)
wrote:
> > As discussed in [1], we're taking this opportunity to return some patchsets
> > that don't appear to be ge
On Wed, Aug 3, 2022 at 8:42 PM Shinoda, Noriyoshi (PN Japan FSIP)
wrote:
> > As discussed in [1], we're taking this opportunity to return some patchsets
> > that don't appear to be getting enough reviewer interest.
> Thank you for your helpful comments.
> As you say, my patch doesn't seem to be
m Lane
; Kyotaro Horiguchi
Subject: Re: Improve logging when using Huge Pages
As discussed in [1], we're taking this opportunity to return some patchsets
that don't appear to be getting enough reviewer interest.
This is not a rejection, since we don't necessarily think there's anything
unacceptable
As discussed in [1], we're taking this opportunity to return some
patchsets that don't appear to be getting enough reviewer interest.
This is not a rejection, since we don't necessarily think there's
anything unacceptable about the entry, but it differs from a standard
"Returned with Feedback" in
; Kyotaro Horiguchi
Subject: Re: Improve logging when using Huge Pages
On Tue, Nov 2, 2021 at 1:24 AM Fujii Masao wrote:
>
>
>
> On 2021/10/29 7:05, Justin Pryzby wrote:
> > Hi,
> >
> > On Wed, Oct 27, 2021 at 06:39:46AM +, Shinoda, Noriyoshi (PN Japan
> >
On Tue, Nov 2, 2021 at 1:24 AM Fujii Masao wrote:
>
>
>
> On 2021/10/29 7:05, Justin Pryzby wrote:
> > Hi,
> >
> > On Wed, Oct 27, 2021 at 06:39:46AM +, Shinoda, Noriyoshi (PN Japan
> > FSIP) wrote:
> >> Thank you for your comment.
> >> The attached patch stops message splitting.
> >> This
...@oss.nttdata.com]
Sent: Tuesday, November 2, 2021 11:35 PM
To: Shinoda, Noriyoshi (PN Japan FSIP) ;
pgsql-hack...@postgresql.org; Masahiko Sawada
Cc: rjuju...@gmail.com; t...@sss.pgh.pa.us; Kyotaro Horiguchi
; Justin Pryzby
Subject: Re: Improve logging when using Huge Pages
On 2021/11/02
On 2021/11/02 18:31, Shinoda, Noriyoshi (PN Japan FSIP) wrote:
Fujii-san, Sawada-san,
Thank you for your comment.
Also, with the patch, the log message is emitted also during initdb and
starting up in single user mode:
Certainly the log output when executing the initdb command was a
rjuju...@gmail.com; t...@sss.pgh.pa.us;
Kyotaro Horiguchi ; Justin Pryzby
Subject: Re: Improve logging when using Huge Pages
On 2021/10/29 16:00, Masahiko Sawada wrote:
> Which is noisy. Perhaps it's better to log it only when
> IsPostmasterEnvironment is true.
+1
Regards,
--
Fujii Ma
On 2021/10/29 16:00, Masahiko Sawada wrote:
Which is noisy. Perhaps it's better to log it only when
IsPostmasterEnvironment is true.
+1
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/10/29 7:05, Justin Pryzby wrote:
Hi,
On Wed, Oct 27, 2021 at 06:39:46AM +, Shinoda, Noriyoshi (PN Japan FSIP)
wrote:
Thank you for your comment.
The attached patch stops message splitting.
This patch also limits the timing of message output when huge_pages = try and
HugePages
On Wed, Oct 27, 2021 at 3:40 PM Shinoda, Noriyoshi (PN Japan FSIP)
wrote:
>
> Hi,
> Thank you for your comment.
> The attached patch stops message splitting.
> This patch also limits the timing of message output when huge_pages = try and
> HugePages is not used.
>
I've looked at the patch. Here
Hi,
On Wed, Oct 27, 2021 at 06:39:46AM +, Shinoda, Noriyoshi (PN Japan FSIP)
wrote:
> Thank you for your comment.
> The attached patch stops message splitting.
> This patch also limits the timing of message output when huge_pages = try and
> HugePages is not used.
Thanks for updating the
, October 22, 2021 11:38 AM
To: Shinoda, Noriyoshi (PN Japan FSIP)
Cc: masao.fu...@oss.nttdata.com; pgsql-hack...@postgresql.org;
rjuju...@gmail.com; t...@sss.pgh.pa.us; Kyotaro Horiguchi
Subject: Re: Improve logging when using Huge Pages
+ ereport(LOG, (errmsg("Anonymous s
+ ereport(LOG, (errmsg("Anonymous shared memory was allocated %s
huge pages.", with_hugepages ? "with" : "without")));
You shouldn't break a sentence into pieces like this, since it breaks
translation. You don't want an untranslated "without" to appear in the middle
of the
Cc: masao.fu...@oss.nttdata.com; Shinoda, Noriyoshi (PN Japan FSIP)
; pgsql-hack...@postgresql.org; rjuju...@gmail.com;
t...@sss.pgh.pa.us
Subject: Re: Improve logging when using Huge Pages
At Tue, 21 Sep 2021 19:23:22 -0500, Justin Pryzby wrote
in
> On Wed, Sep 22, 2021 at 02:03:11AM +0900,
At Tue, 21 Sep 2021 19:23:22 -0500, Justin Pryzby wrote
in
> On Wed, Sep 22, 2021 at 02:03:11AM +0900, Fujii Masao wrote:
> > Another idea is to output "Anonymous shared memory was allocated with
> > huge pages" when it's successfully allocated with huge pages, and to output
> > "Anonymous
On Wed, Sep 22, 2021 at 02:03:11AM +0900, Fujii Masao wrote:
> Another idea is to output "Anonymous shared memory was allocated with
> huge pages" when it's successfully allocated with huge pages, and to output
> "Anonymous shared memory was allocated without huge pages"
> when it's
On 2021/09/20 17:55, Shinoda, Noriyoshi (PN Japan FSIP) wrote:
I was worried about the same thing as you.
So the attached patch gets the value of the kernel parameter vm.nr_hugepages,
and if it is the default value of zero, the log level is the same as before.
On the other hand, if any value
ju...@gmail.com;
t...@sss.pgh.pa.us
Subject: Re: Improve logging when using Huge Pages
At Fri, 17 Sep 2021 00:13:41 +0900, Fujii Masao
wrote in
>
>
> On 2021/09/08 11:17, Kyotaro Horiguchi wrote:
> > I don't dislike the message, but I'm not sure I like the message is
> > too
At Fri, 17 Sep 2021 00:13:41 +0900, Fujii Masao
wrote in
>
>
> On 2021/09/08 11:17, Kyotaro Horiguchi wrote:
> > I don't dislike the message, but I'm not sure I like the message is
> > too verbose, especially about it has DETAILS. It seems to me something
> > like the following is sufficient,
On 2021/09/08 11:17, Kyotaro Horiguchi wrote:
I don't dislike the message, but I'm not sure I like the message is
too verbose, especially about it has DETAILS. It seems to me something
like the following is sufficient, or I'd like see it even more concise.
"fall back anonymous shared memory
On 2021/09/07 22:16, Justin Pryzby wrote:
On Tue, Sep 07, 2021 at 07:12:36PM +0900, Fujii Masao wrote:
One big concern about the patch is that log message is always reported
when shared memory fails to be allocated with huge pages enabled
when huge_pages=try. Since huge_pages=try is the
Thanks!
At Wed, 8 Sep 2021 07:52:35 +, "Shinoda, Noriyoshi (PN Japan FSIP)"
wrote in
> Hello,
>
> Thank you everyone for comments.
> I have attached a patch that simply changed the message like the advice from
> Horiguchi-san.
>
> > Even with the patch, there are still some cases where
m;
t...@sss.pgh.pa.us
Subject: Re: Improve logging when using Huge Pages
At Tue, 7 Sep 2021 08:16:53 -0500, Justin Pryzby wrote
in
> On Tue, Sep 07, 2021 at 07:12:36PM +0900, Fujii Masao wrote:
> > One big concern about the patch is that log message is always
> > reported when shared
At Tue, 7 Sep 2021 08:16:53 -0500, Justin Pryzby wrote
in
> On Tue, Sep 07, 2021 at 07:12:36PM +0900, Fujii Masao wrote:
> > One big concern about the patch is that log message is always reported
> > when shared memory fails to be allocated with huge pages enabled
> > when huge_pages=try. Since
On Tue, Sep 07, 2021 at 07:12:36PM +0900, Fujii Masao wrote:
> One big concern about the patch is that log message is always reported
> when shared memory fails to be allocated with huge pages enabled
> when huge_pages=try. Since huge_pages=try is the default setting,
> many users would see this
On 2021/09/07 13:09, Shinoda, Noriyoshi (PN Japan FSIP) wrote:
Hello,
Thank you everyone for comments.
In the thread [1] that Horiguchi told me about, there is already a review going
on about GUC for HugePages memory.
For this reason, I have removed the new GUC implementation and attached a
) ; rjuju...@gmail.com;
pgsql-hack...@postgresql.org
Subject: Re: Improve logging when using Huge Pages
On 2021/09/03 23:27, Tom Lane wrote:
> Fujii Masao writes:
>> IMO, if the level is promoted to LOG, the message should be updated
>> so that it follows the error message sty
On 2021/09/03 23:27, Tom Lane wrote:
Fujii Masao writes:
IMO, if the level is promoted to LOG, the message should be updated
so that it follows the error message style guide. But I agree that simpler
message would be better in this case. So what about something like
the following?
LOG:
Fujii Masao writes:
> IMO, if the level is promoted to LOG, the message should be updated
> so that it follows the error message style guide. But I agree that simpler
> message would be better in this case. So what about something like
> the following?
> LOG: could not map anonymous shared
On 2021/09/03 16:49, Kyotaro Horiguchi wrote:
IF you are thinking to show that in GUC, you might want to look into
the nearby thread [1]
Yes, let's discuss this feature at that thread.
I have some comment about the patch.
- if (huge_pages == HUGE_PAGES_TRY && ptr ==
Hello.
At Fri, 3 Sep 2021 06:28:58 +, "Shinoda, Noriyoshi (PN Japan FSIP)"
wrote in
> Fujii-san, Julien-san
>
> Thank you very much for your comment.
> I followed your comment and changed the elog function to ereport function and
> also changed the log level. The output message is the
ards,
Noriyoshi Shinoda
-Original Message-
From: Fujii Masao [mailto:masao.fu...@oss.nttdata.com]
Sent: Wednesday, September 1, 2021 2:06 AM
To: Julien Rouhaud ; Shinoda, Noriyoshi (PN Japan FSIP)
Cc: pgsql-hack...@postgresql.org
Subject: Re: Improve logging when using Huge Pages
On 2
On 2021/08/31 15:57, Julien Rouhaud wrote:
On Tue, Aug 31, 2021 at 1:37 PM Shinoda, Noriyoshi (PN Japan FSIP)
wrote:
In the current version, when GUC huge_pages=try, which is the default setting,
no log is output regardless of the success or failure of the HugePages
acquisition. If you
On Tue, Aug 31, 2021 at 1:37 PM Shinoda, Noriyoshi (PN Japan FSIP)
wrote:
>
> In the current version, when GUC huge_pages=try, which is the default
> setting, no log is output regardless of the success or failure of the
> HugePages acquisition. If you want to output logs, you need to set
>
Hi Hackers,
In the current version, when GUC huge_pages=try, which is the default setting,
no log is output regardless of the success or failure of the HugePages
acquisition. If you want to output logs, you need to set
log_min_messages=DEBUG3, but it will output a huge amount of extra logs.
93 matches
Mail list logo
