Re: relation OID in ReorderBufferToastReplace error message

On 2021-Sep-23, Jeremy Schneider wrote:

> On 9/22/21 20:11, Amit Kapila wrote:
> >
> > On Thu, Sep 23, 2021 at 3:06 AM Jeremy Schneider <schnjere(at)amazon(dot)com> wrote:
> >>
> >> Any chance of back-patching this?
> >
> > Normally, we don't back-patch code improvements unless they fix some
> > bug or avoid future back-patch efforts. So, I am not inclined to
> > back-patch this but if others also feel strongly about this then we
> > can consider it.
>
> The original thread about the logical replication bugs spawned a few
> different threads and code changes. The other code changes coming out of
> those threads were all back-patched, but I guess I can see arguments
> both ways on this one.

I think that for patches that are simple debugging aids we do
backpatch, with the intent to get them deployed in users' systems as
soon and as widely possible. I did that in this one, for example

Author: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Branch: master [961dd7565] 2021-08-30 16:29:12 -0400
Branch: REL_14_STABLE [eae08e216] 2021-08-30 16:29:12 -0400
Branch: REL_13_STABLE [6197d7b53] 2021-08-30 16:29:12 -0400
Branch: REL_12_STABLE [fa8ae19be] 2021-08-30 16:29:12 -0400
Branch: REL_11_STABLE [0105b7aaa] 2021-08-30 16:29:12 -0400
Branch: REL_10_STABLE [02797ffa9] 2021-08-30 16:29:12 -0400
Branch: REL9_6_STABLE [37e468252] 2021-08-30 16:29:12 -0400

Report tuple address in data-corruption error message

Most data-corruption reports mention the location of the problem, but
this one failed to. Add it.

Backpatch all the way back. In 12 and older, also assign the
ERRCODE_DATA_CORRUPTED error code as was done in commit fd6ec93bf890 for
13 and later.

Discussion: https://postgr.es/m/202108191637.oqyzrdtnheir@alvherre.pgsql

--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
"I'm impressed how quickly you are fixing this obscure issue. I came from
MS SQL and it would be hard for me to put into words how much of a better job
you all are doing on [PostgreSQL]."
Steve Midgley, http://archives.postgresql.org/pgsql-sql/2008-08/msg00000.php