| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | Kouber Saparev <kouber(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BF mamba failure |
| Date: | 2024-10-16 00:43:48 |
| Message-ID: | Zw8MRH2ks_BgLTa-@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Oct 11, 2024 at 08:18:58AM +0000, Bertrand Drouvot wrote:
> On Fri, Oct 11, 2024 at 11:07:29AM +0300, Kouber Saparev wrote:
>> Unfortunately not, we are running 15.4 and planning to upgrade very soon.
>> Is the patch mentioned already merged in PostgreSQL 16?
>
> Yes, as of 16.4.
Right. I'd surely welcome more eyes on what I have posted here:
https://www.postgresql.org/message-id/Zm-8Xo93K9yD9fy7@paquier.xyz
I am a bit annoyed by the fact of making PgStatShared_HashEntry
slightly larger to track the age of the entries, especially as this
comes down to being useful only when OID wraparound for all stats
kinds (well, except replslot data, because slot IDs can be more
aggressive or custom pgstats), but I don't really have a brighter idea
for the reason that this is something that we need to track at
entry-level to be able to tell across backends when a single stats
dshash entry can or cannot be reused.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2024-10-16 01:10:06 | Fixing Hash Join bug I caused with adf97c156 |
| Previous Message | Michael Paquier | 2024-10-16 00:31:49 | Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. |