Re: Skip collecting decoded changes of already-aborted transactions - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Skip collecting decoded changes of already-aborted transactions
Date
Msg-id CAFiTN-sqmsCFDD_eBUAjyp7Snqbw7amO_4fxLod3xKNbHRupNA@mail.gmail.com
Whole thread Raw
In response to Re: Skip collecting decoded changes of already-aborted transactions  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Skip collecting decoded changes of already-aborted transactions
List pgsql-hackers
On Fri, Dec 13, 2024 at 3:01 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> DDLs write not only XLOG_XACT_INVALIDATIONS but also system catalog
> changes. I think that when decoding these system catalog changes, we
> end up calling SnapBuildProcessChange(). I understand that decoding
> XLOG_XACT_INVALIDATIONS doesn't call SnapBuildProcessChange() but
> queues invalidation messages to the reorderbuffer, but I still don't
> understand cases where a transaction entry is quite big and has only a
> lot of invalidation messages.

You are right that SnapBuildProcessChange() will be called when there
are changes in the system catalog.  However it is very much possible
that when you are processing the system catalog operation the
snapbuild state is not yet SNAPBUILD_FULL_SNAPSHOT and by the time you
reach to XLOG_XACT_INVALIDATIONS some concurrent transaction get
committed and snapbuild state change to SNAPBUILD_FULL_SNAPSHOT.
However, I need to agree that such a transaction can not really be
very large because this can contain Invalidation messages at max from
a single DDL command so maybe we don't need to do anything special for
them and we can go ahead with the approach you followed in the current
patch.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Reject Windows command lines not convertible to system locale
Next
From: Robert Treat
Date:
Subject: Re: Eagerly scan all-visible pages to amortize aggressive vacuum