Re: logical decoding bug: segfault in ReorderBufferToastReplace()

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Jeremy Schneider <schnjere(at)amazon(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: logical decoding bug: segfault in ReorderBufferToastReplace()
Date: 2021-06-09 03:33:17
Message-ID: CAA4eK1+deBBnMVPxfLuv1Aa7tuh-7e3FvnSvWTaCy4-_HPcBLg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-committers pgsql-hackers

On Wed, Jun 9, 2021 at 12:06 AM Jeremy Schneider <schnjere(at)amazon(dot)com> wrote:
>
> On 6/4/21 23:42, Amit Kapila wrote:
>
> On 2021-Jun-04, Jeremy Schneider wrote:
>
> ERROR: XX000: could not open relation with OID 0
> LOCATION: ReorderBufferToastReplace, reorderbuffer.c:305
>
> Even, if this fixes the issue, I guess it is better to find why this
> happens? I think the reason why the code is giving an error is that
> after toast insertions we always expect the insert on the main table
> of toast table, but if there happens to be a case where after toast
> insertion, instead of getting the insertion on the main table we get
> an insert in some other table then you will see this error. I think
> this can happen for speculative insertions where insertions lead to a
> toast table insert, then we get a speculative abort record, and then
> insertion on some other table. The main thing is currently decoding
> code ignores speculative aborts due to which such a problem can occur.
> Now, there could be other cases where such a problem can happen but if
> my theory is correct then the patch we are discussing in the thread
> [1] should solve this problem.
>
> Jeremy, is this problem reproducible? Can we get a testcase or
> pg_waldump output of previous WAL records?
>
> [1] - https://www.postgresql.org/message-id/CAExHW5sPKF-Oovx_qZe4p5oM6Dvof7_P%2BXgsNAViug15Fm99jA%40mail.gmail.com
>
>
> It's unclear to me whether or not we'll be able to catch the repro on the actual production system. It seems that we are hitting this somewhat consistently, but at irregular and infrequent intervals. If we are able to catch it and walk the WAL records then I'll post back here.
>

Okay, one thing you can check is if there is a usage of Insert .. On
Conflict .. statement in the actual production system?

> FYI, Bertrand was able to replicate the exact error message with pretty much the same repro that's in the other email thread which is linked above.
>
> Separately, would there be any harm in adding the relation OID to the error message? Personally, I just think the error message is generally more useful if it shows the main relation OID (since we know that the toast OID can be 0). Not a big deal though.
>

I don't think that is a bad idea. However, I think it might be better
to propose that as a separate patch in a new thread.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Przemysław Biernat 2021-06-09 05:06:42 Re: Problem with the Polish language
Previous Message Tom Lane 2021-06-09 03:20:50 Re: setting the timezone parameter with space cause diff result

Browse pgsql-committers by date

  From Date Subject
Next Message Drouvot, Bertrand 2021-06-09 06:07:24 Re: logical decoding bug: segfault in ReorderBufferToastReplace()
Previous Message Tom Lane 2021-06-08 22:40:23 pgsql: Force NO SCROLL for plpgsql's implicit cursors.

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-06-09 03:46:27 Re: Error on pgbench logs
Previous Message Tom Lane 2021-06-09 03:32:21 Re: Move pg_attribute.attcompression to earlier in struct for reduced size?