Re: Error handling in after-startup shmem requests

From: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Error handling in after-startup shmem requests
Date: 2026-08-29 08:45:42
Message-ID: CAJTYsWVYzZxCHp3EZ9CtRL-t2m450GxqbTtcc1Tj9YqmXfttNQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Sat, 29 Aug 2026 at 02:35, Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2026-08-28 17:58:55 +0300, Heikki Linnakangas wrote:
> > On 26/08/2026 15:44, Ayush Tiwari wrote:
> > > I took a quick look and triggered the tests parallely.
> > >
> > > Patch looks good to me.
> >
> > Committed, thanks!
>
> This test reliably fails for me locally. I think it may be due to my system
> having huge pages configured and the default of the huge_pages GUC being
> try. When using huge pages, we round up the allocation, which increases the
> reserve. Which then triggers the test to fail to fail, as the reserve is
> bigger than 128kB.
>

Thanks for the report.

The attached patch disables huge pages immediately before the allocation-
failure phase. This keeps the test focused on recovery from an allocation
failure rather than on the platform's shared memory segment rounding.

Regards,
Ayush

Attachment Content-Type Size
v1-0001-Make-after-startup-shmem-failure-test-reliable.patch application/octet-stream 1.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message 贾明伟 2026-08-29 10:00:46 回复:[RFC] Umbra: physical remapping, protection mechanisms, and write amplification
Previous Message ZizhuanLiu X-MAN 2026-08-29 07:27:48 Re: Fix var_eq_const: sum selectivity of all matching MCV entries instead of stopping at first match