From: Andres Freund <andres@anarazel.de>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: david_sisson@dell.com, pgsql-bugs@lists.postgresql.org, PG Bug reporting form <noreply@postgresql.org>
Subject: Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes
Date: Sat, 21 Jan 2023 15:29:22 -0800
Message-ID: <20230121232922.juo7t3fhaso7qh3s@awork3.anarazel.de> (raw)
In-Reply-To: <4ce40288-5b88-f9fb-ea11-fc932c61472b@enterprisedb.com>
References: <17757-dbdfc1f1c954a6db@postgresql.org>
<4ce40288-5b88-f9fb-ea11-fc932c61472b@enterprisedb.com>
Hi,
On 2023-01-22 00:10:29 +0100, Tomas Vondra wrote:
> On 1/20/23 23:48, PG Bug reporting form wrote:
> > In these cases, the initdb phase will attempt to allocate huge pages that
> > are available in the OS, but it will be denied access by Kubernetes and
> > fail.
>
> Well, so how exactly this fails? Does that mean Kubernetes broke mmap()
> with MAP_HUGETLB so that it doesn't return MAP_FAILED when hugepages are
> not available, or what? Because that's the only explanation I can see,
> looking at the code.
Yea, that's what I was wondering about as well.
> Or it just does not realize there are no hugepages, returns something
> and then crashes with SIGBUS later when trying to access it?
I assume that that's the case. There's references to bus errors in a bunch of
the linked issues. E.g.
https://github.com/CrunchyData/postgres-operator/issues/413
selecting default max_connections ... sh: line 1: 60 Bus error (core dumped) "/usr/pgsql-10/bin/postgres" --boot -x0 -F -c max_connections=100 -c shared_buffers=1000 -c dynamic_shared_memory_type=none < "/dev/null" > "/dev/null" 2>&1
It's possible that the problem would go away if we used MAP_POPULATE for the
allocation.
I'd guess that this is annoying cgroups stuff :(
> I doubt we want to just go straight to changing the default value for
> everyone. IMHO if the "try" logic is somehow broken, we should fix the
> try logic, not mess with the defaults.
Agreed. But we could disable huge pages explicitly inside initdb - there's
really no point in using it there...
Greetings,
Andres Freund
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: andres@anarazel.de, tomas.vondra@enterprisedb.com, noreply@postgresql.org
Subject: Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes
In-Reply-To: <20230121232922.juo7t3fhaso7qh3s@awork3.anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox