Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals)
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals) |
| Дата | |
| Msg-id | f7d3fd76-330f-488b-8f2e-722796127ae0@iki.fi обсуждение |
| Ответ на | Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals) (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
| Список | pgsql-hackers |
On 21/02/2026 11:42, Bertrand Drouvot wrote: > On Fri, Feb 20, 2026 at 11:03:09PM +0200, Heikki Linnakangas wrote: >> On 11/02/2026 06:40, Bertrand Drouvot wrote: >>> That looks ok to see PGPROC as an "acceptable" one, if not, should we use the >>> union trick? >> >> It seems acceptable to just not align it if the compiler doesn't support it. >> This is just a performance optimization, after all. > > Agreed. > >> Attached is new versions the remaining patches. I think these are ready to >> be committed. > > Thanks! > > One nit, 0001 is adding the typedef: > > " > -struct PGPROC > +typedef struct PGPROC > . > . > . > -}; > - > -/* NOTE: "typedef struct PGPROC PGPROC" appears in storage/lock.h. */ > + uint32 wait_event_info; /* proc's wait information */ > +} PGPROC; > " > > Would that make more sense to add the typedef when we introduce the explicit > alignment in 0002 (like it was done in your previous > v2-0001-Align-PGPROC-to-cache-line-boundary.patch up-thread)? Yeah, I had it as part of the other commit in the previous version, but decided to make it part of the other one, so that it's more clear what the alignment. I don't think it matters much either way though. Pushed, thanks for the review! - Heikki
В списке pgsql-hackers по дате отправления: