Horton
Menu

Re: Improve logging when using Huge Pages

Nathan Bossart <nathandbossart@gmail.com>

View thread
From: Nathan Bossart <nathandbossart@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Stephen Frost <sfrost@snowman.net>, Andres Freund <andres@anarazel.de>, Michael Paquier <michael@paquier.xyz>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, thomas.munro@gmail.com, tgl@sss.pgh.pa.us, john.naylor@enterprisedb.com, noriyoshi.shinoda@hpe.com, jchampion@timescale.com, sawada.mshk@gmail.com, masao.fujii@oss.nttdata.com, pgsql-hackers@postgresql.org, rjuju123@gmail.com
Date: 2023-03-09T19:52:31Z
Lists: pgsql-hackers 
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 machine) can contain many instances, and each individual
> instance in the server could be using huge pages or not.

Ah, good to know.  I've always considered "server" in this context to mean
the server process(es) for a single instance, but I can see the value in
having different terminology to clearly distinguish the process(es) from
the machine.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add GUC parameter "huge_pages_status"

  2. Add check on initial and boot values when loading GUCs

  3. Clean up some inconsistencies with GUC declarations

  4. Clean up some GUC declarations and comments