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
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 |