Re: Subscription tests fail under CLOBBER_CACHE_ALWAYS

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Subscription tests fail under CLOBBER_CACHE_ALWAYS
Date: 2021-05-22 03:06:33
Message-ID: CA+HiwqFnbV7W7j4S3s8pKaCe58stWMFzTsvUgC7SP2WKC-aSRQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, May 22, 2021 at 6:01 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> > IMHO, it would be better to keep the lowest-level
> > apply_handle_XXX_internal() out of this, because presumably we're only
> > cleaning up the mess in higher-level callers. Somewhat related, one
> > of the intentions behind a04daa97a43, which removed
> > es_result_relation_info in favor of passing the ResultRelInfo
> > explicitly to the executor's lower-level functions, was to avoid bugs
> > caused by failing to set/reset that global field correctly in
> > higher-level callers.
>
> Yeah, that's a fair point, and after some reflection I think that
> repeatedly changing the "active" field of the struct is exactly
> what was bothering me about the v2 patch. So in the attached v3,
> I went back to passing that as an explicit argument. The state
> struct now has no fields that need to change after first being set.

Thanks, that looks good to me.

> I did notice that we could remove some other random arguments
> by adding the LogicalRepRelMapEntry* to the state struct,
> so this also does that.

That seems fine.

BTW, I think we'd need to cherry-pick f3b141c4825 (or maybe parts of
it) into v13 branch for back-patching this.

--
Amit Langote
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-05-22 03:58:07 Re: "Multiple table synchronizations are processed serially" still happens
Previous Message Amit Langote 2021-05-22 02:57:37 Re: Forget close an open relation in ReorderBufferProcessTXN()