Re: [patch] Adding an assertion to report too long hash table name

From: Junwang Zhao <zhjwpku(at)gmail(dot)com>
To: Xiaoran Wang <wxiaoran(at)vmware(dot)com>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [patch] Adding an assertion to report too long hash table name
Date: 2022-09-29 08:09:51
Message-ID: CAEG8a3LFKfROOCqEmXKD0SWN+gDfPLK2CURzHnZfnvs+N+y-Og@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

LGTM
+1

On Thu, Sep 29, 2022 at 9:38 AM Xiaoran Wang <wxiaoran(at)vmware(dot)com> wrote:
>
> Hi,
>
> The max size for the shmem hash table name is SHMEM_INDEX_KEYSIZE - 1.
> but when the caller uses a longer hash table name, it doesn't report any error, instead
> it just uses the first SHMEM_INDEX_KEYSIZE -1 chars as the hash table name.
>
> I created some shmem hash tables with the same prefix which was longer than
> SHMEM_INDEX_KEYSIZE - 1, and the size of those hash tables were the same,
> then only one hash table was created. But I thought those hash tables were created
> successfully.
>
> I know this is a corner case, but it's difficult to figure it out when run into it. So I add
> an assertion to prevent it.
>
>
> Thanks,
> Xiaoran

--
Regards
Junwang Zhao

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2022-09-29 08:10:09 Re: Obsolete comment in ExecInsert()
Previous Message Jaime Casanova 2022-09-29 07:55:40 Re: pgsql: Avoid improbable PANIC during heap_update.