Re: Segfault when running postgres inside kubernetes with huge pages

From: Siegfried Kiermayer <sicaine(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Segfault when running postgres inside kubernetes with huge pages
Date: 2023-11-08 15:03:53
Message-ID: CAC-et2exhx4eH8chY0c62k72wqaMHfb9cFvQKv4nqJ5uM+QEEw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

we do run kernel 5.8 and the allocation happens basically at start.

I would still expect postgres to fail gracefully at this point?

Is 'throwing an error message' / checking the allocation a performance
issue? is it in a generic hotpath for allocation?

Tx,

Sigi

On Wed, 8 Nov 2023 at 15:57, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Siegfried Kiermayer <sicaine(at)gmail(dot)com> writes:
> > we are using zalando postgres operator and i changed / set huge pages
> > on kubernetes nodes from something undefined to 1536 (undefined
> > because i was pretty sure before changing it to 1536 i saw an initial
> > value of 1024 with 670 in use.
>
> This previous discussion might hold the clue:
>
> https://www.postgresql.org/message-id/CAFpoUr1ggmGs8qpoKvYxNBO3h-T-n%2BMNh%2BJnLRYsYhHurVOiGQ%40mail.gmail.com
>
> > I would go into more detail but honestly I believe this might be easy
> > to find and I also assume it shouldn't segfault but return an error
> > message indicating the / a issue.
>
> There is not that much we can do about operating system bugs.
>
> regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrei Lepikhov 2023-11-08 15:42:10 Re: BUG #18187: Unexpected error: "variable not found in subplan target lists" triggered by JOIN
Previous Message Tom Lane 2023-11-08 14:57:26 Re: Segfault when running postgres inside kubernetes with huge pages