Re: Fix bug in multixact Oldest*MXactId initialization and access - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Fix bug in multixact Oldest*MXactId initialization and access
Date
Msg-id 231cd950-73e9-4db5-a516-c5216af7b93a@iki.fi
Whole thread Raw
In response to Fix bug in multixact Oldest*MXactId initialization and access  (Yura Sokolov <y.sokolov@postgrespro.ru>)
Responses Re: Fix bug in multixact Oldest*MXactId initialization and access
List pgsql-hackers
(added back pgsql-hackers, I think you replied in private by accident)

On 28/02/2026 00:07, Sami Imseih wrote:
> 1/
> 
> +MyOldestMemberMXactIdSlot(void)
> +{
> +       Assert(MyProcNumber >= 0 && MyProcNumber < MaxBackends);
> 
> It would be better to use NumVisibleSlots instead of MaxBackends in
> the second assert condition.

MaxBackends makes the assertion more strict. It verifies that we use one 
of the slots reserved for regular backends, not prepared xacts. I'll add 
a comment on that.

> 2/
> 
> +static inline MultiXactId *
> +PreparedXactOldestMemberMXactIdSlot(ProcNumber procno)
> +{
> +       Assert(procno >= FIRST_PREPARED_XACT_PROC_NUMBER);
> +       Assert(procno - FIRST_PREPARED_XACT_PROC_NUMBER <
> +              NumMemberSlots);
> +       return &OldestMemberMXactId[procno -
> +              FIRST_PREPARED_XACT_PROC_NUMBER];
> +}
> 
> given
> 
> +#define FIRST_PREPARED_XACT_PROC_NUMBER \
> +        (MaxBackends + NUM_AUXILIARY_PROCS)
> 
> let's say, MaxBackends = 100 and NUM_AUXILIARY_PROCS = 38, the
> first prepared transaction procno will be 138. The current math
> will return an index of 0 (138 - 138 = 0), but this corrupts
> backend slot 0. 

Oof, you're right.

> Should we not account for NumVisibleSlots to skip
> over the regular backend slots?
> 
> ```
> return &OldestMemberMXactId[NumVisibleSlots + (procno -
> FIRST_PREPARED_XACT_PROC_NUMBER)];
> ```

That's not quite right either. NumVisibleSlots has nothing to do with 
the OldestMemberMXactId array, MaxBackends is the right offset here. 
NumVisibleSlots == MaxBackends, but that's just a coincidence.

New version attached.

- Heikki

Attachment

pgsql-hackers by date:

Previous
From: Madhav Madhusoodanan
Date:
Subject: Re: [WiP] B-tree page merge during vacuum to reduce index bloat
Next
From: James Pang
Date:
Subject: hot standby failed in read pg_commit_ts