From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Japin Li <japinli(at)hotmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Forget close an open relation in ReorderBufferProcessTXN() |
Date: | 2021-06-01 09:56:24 |
Message-ID: | CAA4eK1LNwXYTOaQOnP4iNgNJfuFSFbr5Tp0Sv-j1OwayPBPRdw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 31, 2021 at 8:51 AM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
>
> On Thu, May 27, 2021 at 3:36 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > On Fri, May 21, 2021 at 1:12 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > >
> >
> > Why do we need to move send_relation_and_attrs() call? I think it
> > doesn't matter much either way but OTOH, in the existing code, if
> > there is an error (say 'out of memory' or some other) while building
> > the map, we won't send relation attrs whereas with your change we will
> > unnecessarily send those in such a case.
>
> That's a good point. I've reverted that change in the attached.
>
Pushed.
> > I feel there is no need to backpatch v6-0002. We can just make it a
> > HEAD-only change as that doesn't cause any bug even though it is
> > better not to send it. If we consider it as a HEAD-only change then
> > probably we can register it for PG-15. What do you think?
>
> Okay, I will see about creating a PG15 CF entry for 0002.
>
Thanks!
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2021-06-01 10:09:25 | Re: [BUG]Update Toast data failure in logical replication |
Previous Message | Amit Kapila | 2021-06-01 09:47:27 | Re: Skipping logical replication transactions on subscriber side |