| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | "alvherre(at)alvh(dot)no-ip(dot)org" <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "x4mmm(at)yandex-team(dot)ru" <x4mmm(at)yandex-team(dot)ru>, "a(dot)lubennikova(at)postgrespro(dot)ru" <a(dot)lubennikova(at)postgrespro(dot)ru>, "hlinnaka(at)iki(dot)fi" <hlinnaka(at)iki(dot)fi>, "matsumura(dot)ryo(at)fujitsu(dot)com" <matsumura(dot)ryo(at)fujitsu(dot)com>, "masao(dot)fujii(at)gmail(dot)com" <masao(dot)fujii(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: archive status ".ready" files may be created too early |
| Date: | 2021-08-20 18:40:33 |
| Message-ID: | CA+TgmoZqGTUjykNjTs11HrD8tmRD7S_xRPC_8txsUkrZTSeBxw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Aug 20, 2021 at 1:52 PM alvherre(at)alvh(dot)no-ip(dot)org
<alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> Actually, you were right. Hash tables in shared memory can be expanded.
> There are some limitations (the hash "directory" is fixed size, which
> means the hash table get less efficient if it grows too much), but you
> can definitely create more hash entries than the initial size. See for
> example element_alloc(), which covers the case of a hash table being
> IS_PARTITIONED -- something that only shmem hash tables can be. Note
> that ShmemInitHash passes the HASH_ALLOC flag and uses ShmemAllocNoError
> as allocation function, which acquires memory from the shared segment.
I realize that the code supports this ... but I thought we had
established a policy that only the main lock manager's shared hash
tables, and not any others, are actually allowed to make use of this
functionality. See commit 7c797e7194d969f974abf579cacf30ffdccdbb95.
It seems like a dangerous thing to rely on in any case, since we can't
predict how much extra shared memory might actually be available.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Dilger | 2021-08-20 18:42:09 | Re: Minor pg_amcheck fixes spotted while reading code |
| Previous Message | Mark Dilger | 2021-08-20 18:36:56 | Re: Use extended statistics to estimate (Var op Var) clauses |