Re: Multixact and prepared transactions

Heikki Linnakangas wrote:
> We seem to have neglected prepared transactions in the logic that tracks
> the oldest visible multixact. OldestMemberMXactId doesn't contain
> entries for prepared transactions, so the UPDATE incorrectly considers
> the multixact as an old obsolete one.
>
> A straightforward fix is to enlarge OldestMemberMXactId to make room for
> max_prepared_transactions extra entries, and at prepare transfer the
> value of the current backend to one of those slots.

So here's a patch doing that:

- OldestMemberMXactId is enlarged to make room for prepared transactions
in addition to real backends (enlarged from MaxBackends to
MaxBackends+max_prepared_xacts). OldestVisibleMXactId is enlarged as
well for simplicity, even though the slots for prepared xacts are never
used.

- OldestMemberMXactId of a backend is copied to the slot of the prepared
xact at prepare time, and also stored in the 2pc state file so that it
can be recovered at database startup.

- The arrays are indexed by backend ID, but dummy PGPROCs representing
prepared transactions don't have backend ids. So I invented "dummy
backend IDs", which are unique numbers assigned to all dummy procs,
similar to backend ids for real procs. The dummy backend IDs start from
MaxBackends+1, so we can use it directly as an index into the enlarged
OldestMemberMXactId array.

I considered assigning dummy procs real backend IDs, in
PGPROC->backendId, but backend IDs are used to index the
SISeg->procState array, for example, and there's no entries for prepared
transactions there. While I don't see anything that would break right
now, it seems dangerous.

BTW, I noticed that in deadlock.c, we reserve many working arrays of
size MaxBackends. But prepared transactions can hold locks too, and
therefore can be visited by the deadlock checker. Shouldn't we reserve
space in the arrays for prepared xacts as well? You'll be hard-pressed
to hit that in practice, given that MaxBackends includes room for
autovacuum launcher and worker too, and you'd need to have all backends
involved in the deadlock. But still.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com