From: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
---|---|
To: | Sami Imseih <samimseih(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PgStat_HashKey padding issue when passed by reference |
Date: | 2025-09-22 08:32:41 |
Message-ID: | aNEJqT1CKLmz7i2z@ip-10-97-1-34.eu-west-3.compute.internal |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Thu, Sep 18, 2025 at 11:52:05AM -0500, Sami Imseih wrote:
> > I still want to add it, but it also seemed like you were not much a
> > fan of it, so I did not really want to push forward with something
> > that was not loved. :D
> >
> > Addressing your points, attached is an updated patch labelled v2.
>
> I was not a fan of it, when my idea was to allow flexibility in adding
> more fields to the key. However, I am now convinced objid should be
> good enough.
+ * NB: We assume that this struct contains no padding. Also, 8 bytes
+ * allocated for the object ID are good enough to ensure the uniqueness
+ * of the hash key, hence the addition of new fields is not recommended.
yeah that would also work for [1], where the objoid could then store a spcOid
and a relNumber (so that all the RelFileLocator fields would be stored) means:
dboid (linked to RelFileLocator's dbOid)
objoid (linked to RelFileLocator's spcOid and to the RelFileLocator's relNumber)
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jakub Wartak | 2025-09-22 08:45:12 | Re: postmaster uses more CPU in 18 beta1 with io_method=io_uring |
Previous Message | Jim Jones | 2025-09-22 08:14:04 | Re: We broke the defense against accessing other sessions' temp tables |