Heikki Linnakangas wrote:
> 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
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 straightfo
While reviewing the hot standby patch, I noticed a little existing bug
with multixacts and prepared transactions. If a prepared transaction has
a shared lock on a tuple, represented by a multixact, other backends can
sometimes update the tuple anyway.
Steps to reproduce, using two psql sessions:
