Re: subscription/t/010_truncate.pl failure on desmoxytes in REL_13_STABLE

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: subscription/t/010_truncate.pl failure on desmoxytes in REL_13_STABLE
Date: 2021-06-23 02:37:43
Message-ID: CAA4eK1Kft05mwNuZbTVRmz8SNS3r+uriuCT8DxL5KJy5btoS-A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 22, 2021 at 6:54 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > On Tue, Jun 22, 2021 at 10:01 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >> I see this report is from 16th June 2021 and the commit is on 18th
> >> June 2021. So, I am hoping this should have been fixed but if we see
> >> it again then probably we need to investigate it further.
>
> > Ahh, that makes sense. Thanks for checking, and sorry for the noise.
>
> BTW, the reason that the walsender is still showing its "query" as
> "SELECT pg_config..." is that pre-v14 versions don't update the
> reported query for replication commands, only plain-SQL commands.
> I recall that we fixed that in HEAD awhile ago; should we consider
> back-patching something for it?
>

I think it would be great if we can do that. Analyzing such failures
and in general for replication errors that will be a nice improvement
and make the jobs of many people a bit easier.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-06-23 02:53:31 Re: Optionally automatically disable logical replication subscriptions on error
Previous Message Greg Nancarrow 2021-06-23 02:11:06 Re: Parallel scan with SubTransGetTopmostTransaction assert coredump