Re: logical decoding bug: segfault in ReorderBufferToastReplace() - Mailing list pgsql-bugs

From Dilip Kumar
Subject Re: logical decoding bug: segfault in ReorderBufferToastReplace()
Date
Msg-id CAFiTN-vSHa5w0g6YjYjP=q0ZkqgVGwZ2ksCmsSXZqzAKNYpyww@mail.gmail.com
Whole thread Raw
In response to Re: logical decoding bug: segfault in ReorderBufferToastReplace()  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-bugs
On Sat, Jun 5, 2021 at 5:41 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> > This indicates that a toast record was present for that relation,
> > despite:
>
> Can you explain what it is you saw that indicates that a toast record
> was present for the relation?  I may be misreading the code, but there's
> nothing obvious that says that if we reach there, then a toast datum
> exists anywhere for this relation.  We only know that txn->toast_hash is
> set, but that could be because the transaction touched a toast record in
> some other table.  Right?

Is this problem is related to the thread [1], where due to spec abort
the toast hash was not deleted and after that, if the next record is
for some other relation which is not having a toast table you will see
this error.  There are a few other problems if the toast hash is not
cleaned due to spec abort.  I have submitted patches with 2 approached
in that thread.


[1] https://www.postgresql.org/message-id/CAFiTN-szfpMXF2H%2Bmk3m_9AB610v103NTv7Z1E8uDBr9iQg1gg%40mail.gmail.com

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17048: about trace_locks parameter problem
Next
From: Noah Misch
Date:
Subject: Re: BUG #16961: Could not access status of transaction