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@amazon.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@alvh.no-ip.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