Horton

Re: pgsql: Separate RecoveryConflictReasons from procsignals

Heikki Linnakangas <hlinnaka@iki.fi>

View thread View on postgr.es
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: pgsql-committers@lists.postgresql.org
Date: 2026-02-10T15:52:16Z
Lists: pgsql-hackers 
On 10/02/2026 17:19, Bertrand Drouvot wrote:
> Hi,
> 
> On Tue, Feb 10, 2026 at 02:32:37PM +0000, Heikki Linnakangas wrote:
>> Separate RecoveryConflictReasons from procsignals
>>
>> Share the same PROCSIG_RECOVERY_CONFLICT flag for all recovery
>> conflict reasons. To distinguish, have a bitmask in PGPROC to indicate
>> the reason(s).
> 
> I did not look at the thread, so sorry to be late, but that makes the size of PGPROC
> going from 832 to 840 bytes, so not a multiple of 64 anymore. Is that something
> to worry about? (same kind of discussion in [1]).
> 
> [1]: https://postgr.es/m/tw53roer2j4quxh7vlyv62drc5fo6c6zdltvl6d2dttqa62uhi%40stwlpdwlftpj

Right, that's a fair question. I hope the cache line alignment is not 
critical for performance, because the alignment is completely accidental 
today. I checked the size on different versions:

master:  840 (after this commit)
v18:     832
v17:     888
v14-v16: 880

So v18 was the outlier in that it happened to be 64-byte aligned.

If there's a performance reason to keep have it be aligned - and maybe 
there is - we should pad it explicitly.

- Heikki

Commits

  1. Use C11 alignas in typedef definitions

  2. Align PGPROC to cache line boundary

  3. Rearrange fields in PGPROC, for clarity

  4. Split PGPROC 'links' field into two, for clarity

  5. Remove useless store to local variable

  6. Separate RecoveryConflictReasons from procsignals