On Wed, Nov 4, 2020 at 9:02 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Nov 4, 2020 at 3:01 PM Ajin Cherian <itsajin@gmail.com> wrote:
> >
> > On Mon, Nov 2, 2020 at 9:40 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Wed, Oct 28, 2020 at 10:50 AM Peter Smith <smithpb2250@gmail.com> wrote:
> > > 2.
> > > +DecodePrepare(LogicalDecodingContext *ctx, XLogRecordBuffer *buf,
> > > + xl_xact_parsed_prepare * parsed)
> > > +{
> > > ..
> > > + if (SnapBuildXactNeedsSkip(ctx->snapshot_builder, buf->origptr) ||
> > > + (parsed->dbId != InvalidOid && parsed->dbId != ctx->slot->data.database) ||
> > > + ctx->fast_forward || FilterByOrigin(ctx, origin_id))
> > > + return;
> > > +
> > >
> > > I think this check is the same as the check in DecodeCommit, so you
> > > can write some comments to indicate the same and also why we don't
> > > need to call ReorderBufferForget here. One more thing is to note is
> > > even if we don't need to call ReorderBufferForget here but still we
> > > need to execute invalidations (which are present in top-level txn) for
> > > the reasons mentioned in ReorderBufferForget. Also, if we do this,
> > > don't forget to update the comment atop
> > > ReorderBufferImmediateInvalidation.
> >
> > I have updated the comments. I wasn't sure of when to execute
> > invalidations. Should I only
> > execute invalidations if this was for another database than what was
> > being decoded or should
> > I execute invalidation every time we skip?
> >
>
> I think so. Did there exist any such special condition in DecodeCommit
> or do you have any other reason in your mind for not doing it every
> time we skip? We probably might not need to execute when the database
> is different (at least I can't think of a reason for the same) but I
> guess this doesn't make much difference and it will keep the code
> consistent with what we do in DecodeCommit.
>
I was just basing it on the comments in the DecodeCommit:
* We can't just use ReorderBufferAbort() here, because we need to execute
* the transaction's invalidations. This currently won't be needed if
* we're just skipping over the transaction because currently we only do
* so during startup, to get to the first transaction the client needs. As
* we have reset the catalog caches before starting to read WAL, and we
* haven't yet touched any catalogs, there can't be anything to invalidate.
* But if we're "forgetting" this commit because it's it happened in
* another database, the invalidations might be important, because they
* could be for shared catalogs and we might have loaded data into the
* relevant syscaches.
regards,
Ajin Cherian
Fujitsu Australia
