From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Marking shared buffer lookup table as HASH_FIXED_SIZE |
Date: | 2025-09-18 09:10:16 |
Message-ID: | CAExHW5vx_kzJxzg2e0FdCZq3HBxd9p_hjhsgHv4u8_z944gFwA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 18, 2025 at 6:14 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2025-08-26 19:55:21 +0530, Ashutosh Bapat wrote:
> > StrategyInitialize() calls InitBufTable() passing the maximum number
> > of possible entries in the shared buffer lookup table. The table can
> > not have more entries than the number of available shared buffers +
> > number of partitions as explained in the comment in
> > StrategyInitialize(). If there are more than those entries something
> > is wrong with the hash table like mapping two different pages to the
> > same buffer. InitBufTable() invokes ShmemInitHash() with the same init
> > and max size. This means that the maximum number of entries are
> > allocated right from the beginning. So there should not be any need to
> > allocate more entries after initial setup. Thus the hash table
> > qualifies to be marked as HASH_FIXED_SIZE, so that we don't end up
> > with a corrupted hash table in case of a bug.
> >
> > Here's a patch to do so.
>
> Makes sense to me. Applied.
Thanks.
--
Best Wishes,
Ashutosh Bapat
From | Date | Subject | |
---|---|---|---|
Next Message | Álvaro Herrera | 2025-09-18 09:23:06 | Re: someone else to do the list of acknowledgments |
Previous Message | John Naylor | 2025-09-18 08:53:08 | Re: GB18030-2022 Support in PostgreSQL |