From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Magnus Hagander <magnus(at)hagander(dot)net>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Don Seiler <don(at)seiler(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Estimating HugePages Requirements? |
Date: | 2021-09-03 17:36:43 |
Message-ID: | 7ED221D0-0D75-46F8-8D6C-8AF70D8EABE7@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers |
On 9/2/21, 6:46 PM, "Michael Paquier" <michael(at)paquier(dot)xyz> wrote:
> On Thu, Sep 02, 2021 at 04:46:56PM +0000, Bossart, Nathan wrote:
>> Yeah, huge_pages_required might not serve much purpose for Windows.
>> We could always set it to -1 for Windows if it seems like it'll do
>> more harm than good.
>
> I'd be fine with this setup on environments where there is no need for
> it.
I did this in v5.
> One thing that would be incorrect upon more review is that we'd still
> have data_checksums wrong with -C, meaning that the initial read of
> the control file should be moved further up, and getting the control
> file checks done before registering workers would be better. Keeping
> the lock file at the end would be fine AFAIK, but should we worry
> about the interactions with _PG_init() here?
I think we can avoid so much reordering by moving the -C handling
instead. That should also fix things like data_checksums. I split
the reordering part out into its own patch in v5.
You bring up an interesting point about _PG_init(). Presently, you
can safely assume that the data directory is locked during _PG_init(),
so there's no need to worry about breaking something on a running
server. I don't know how important this is. Most _PG_init()
functions that I've seen will define some GUCs, request some shared
memory, register some background workers, and/or install some hooks.
Those all seem like safe things to do, but I wouldn't be at all
surprised to hear examples to the contrary. In any case, it looks
like the current ordering of these two steps has been there for 15+
years.
If this is a concern, one option would be to disallow running "-C
shared_memory_size" on running servers. That would have to extend to
GUCs like data_checksums and huge_pages_required, too.
> 0001, that refactors the calculation of the shmem size into a
> different routine, is fine as-is, so I'd like to move on and apply
> it.
Sounds good to me.
Nathan
Attachment | Content-Type | Size |
---|---|---|
v5-0001-Move-the-shared-memory-size-calculation-to-its-ow.patch | application/octet-stream | 7.1 KB |
v5-0004-Introduce-huge_pages_required-GUC.patch | application/octet-stream | 7.0 KB |
v5-0003-Introduce-shared_memory_size-GUC.patch | application/octet-stream | 6.7 KB |
v5-0002-Move-postmaster-C-logic-to-after-processing-prelo.patch | application/octet-stream | 2.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bossart, Nathan | 2021-09-03 17:46:05 | Re: Estimating HugePages Requirements? |
Previous Message | Swati Patil | 2021-09-03 09:39:44 | Standby.signal file is not getting deleted after failover in all scanarios |
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2021-09-03 17:42:28 | pgsql: Set the volatility of the timestamptz version of date_bin() back |
Previous Message | Alvaro Herrera | 2021-09-03 17:35:32 | Re: prevent immature WAL streaming |