( a.On Wed, Nov 3, 2021 at 11:44 AM Andrey Borodin <x4...@yandex-team.ru> wrote: > > 21 окт. 2021 г., в 09:01, Kyotaro Horiguchi <horikyota....@gmail.com> > > написал(а): > > > > If the discussion so far is correct, the following diff will fix the > > issue. > > > > diff --git a/src/backend/storage/ipc/procarray.c > > b/src/backend/storage/ipc/procarray.c > > index bd3c7a47fe..19682b73ec 100644 > > --- a/src/backend/storage/ipc/procarray.c > > +++ b/src/backend/storage/ipc/procarray.c > > @@ -4463,6 +4463,12 @@ ExpireOldKnownAssignedTransactionIds(TransactionId > > xid) > > { > > LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE); > > KnownAssignedXidsRemovePreceding(xid); > > + /* > > + * reset lastOverflowedXid if we know transactions that have been > > possiblly > > + * running are being gone. > > + */ > > + if (TransactionIdPrecedes(procArray->lastOverflowedXid, xid)) > > + procArray->lastOverflowedXid = InvalidTransactionId; > > LWLockRelease(ProcArrayLock); > > } > > The patch seems correct bugfix to me. The only question I have: is it right > place from modularity standpoint? procArray->lastOverflowedXid is not a part > of KnownAssignedTransactionIds?
It seems the right place because we take ProcArrayLock here. It would be undesirable to take it twice. We could give a better name for ExpireOldKnownAssignedTransactionIds() indicating that it could modify lastOverflowedXid as well. Any ideas? Should ExpireAllKnownAssignedTransactionIds() be also involved here? ------ Regards, Alexander Korotkov