Re: Improve logging when using Huge Pages

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, sfrost(at)snowman(dot)net, alvherre(at)alvh(dot)no-ip(dot)org, andres(at)anarazel(dot)de, nathandbossart(at)gmail(dot)com, jchampion(at)timescale(dot)com, john(dot)naylor(at)enterprisedb(dot)com, masao(dot)fujii(at)oss(dot)nttdata(dot)com, noriyoshi(dot)shinoda(at)hpe(dot)com, pgsql-hackers(at)postgresql(dot)org, rjuju123(at)gmail(dot)com, sawada(dot)mshk(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, thomas(dot)munro(at)gmail(dot)com
Subject: Re: Improve logging when using Huge Pages
Date: 2023-03-22 02:19:41
Message-ID: ZBplvQx7n0MGVr6O@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. This is the main reason why a GUC would be a better
> > fit, in my opinion, because it makes for a cheaper check, while still
> > allowing a SQL query to check the value of the GUC.
>
> [ Should have read more carefully ]
>
> .. Which is something you cannot do with -C because mmap() happens
> after the runtime-computed logic for postgres -C. It does not sound
> right to do the mmap() for a GUC check, so indeed a function may be
> more adapted rather than move mmap() call a bit earlier in the
> postmaster startup sequence.

On Mon, Mar 20, 2023 at 02:17:33PM +0900, Michael Paquier wrote:
> 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 Horiguchi-san is right.
>
> Yes, I haven't read correctly through. Sorry for the noise.

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.

Most recently, you said it'd be better implemented as a GUC to allow
using -C, but then recanted because -C doesn't work for this (which is
why I implemented it as a string back on 2023-02-08). Which is why I
reset its status on 2023-03-20.

2023-03-22 01:36:58 Michael Paquier (michael-kun) New status: Waiting on Author
2023-03-20 13:05:32 Justin Pryzby (justinpryzby) New status: Needs review
2023-03-20 05:03:53 Michael Paquier (michael-kun) New status: Waiting on Author

--
Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2023-03-22 02:37:03 Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
Previous Message shiy.fnst@fujitsu.com 2023-03-22 02:13:13 RE: Dropped and generated columns might cause wrong data on subs when REPLICA IDENTITY FULL