Date: Fri, 4 Jun 2021 20:07:05 -0400
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Andres Freund <andres@anarazel.de>
Cc: "Drouvot, Bertrand" <bdrouvot@amazon.com>,
	Tomas Vondra <tomas.vondra@2ndquadrant.com>,
	"pgsql-bugs@postgresql.org" <pgsql-bugs@postgresql.org>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	"Schneider (AWS), Jeremy" <schnjere@amazon.com>
Subject: Re: logical decoding bug: segfault in ReorderBufferToastReplace()
Message-ID: <202106050007.hygt5df5ni64@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20191211163522.t2ljtydarlmusoix@alap3.anarazel.de>
Archived-At: 
 <https://www.postgresql.org/message-id/202106050007.hygt5df5ni64%40alvherre.pgsql>
Precedence: bulk

[Resent -- apologies to those who are getting this email twice.  Please
be mindful to reply to this one if you do.  I think the no-crosspost
policy is very obnoxious and should be relaxed.)

On 2019-Dec-11, Andres Freund wrote:

> On 2019-12-11 08:17:01 +0000, Drouvot, Bertrand wrote:
> >     >>Core was generated by `postgres: walsender <NAME-REDACTED>
> >     >><DNS-REDACTED>(31712)'.
> >     >>Program terminated with signal 11, Segmentation fault.
> >     >>#0  ReorderBufferToastReplace (rb=0x3086af0, txn=0x3094a78,
> >     >>relation=0x2b79177249c8, relation=0x2b79177249c8, change=0x30ac938)
> >     >>    at reorderbuffer.c:3034
> >     >>3034    reorderbuffer.c: No such file or directory.
> >     >>...
> >     >>(gdb) #0  ReorderBufferToastReplace (rb=0x3086af0, txn=0x3094a78,
> >     >>relation=0x2b79177249c8, relation=0x2b79177249c8, change=0x30ac938)
> >     >>    at reorderbuffer.c:3034
> >     >>#1  ReorderBufferCommit (rb=0x3086af0, xid=xid@entry=1358809,
> >     >>commit_lsn=9430473346032, end_lsn=<optimized out>,
> >     >>    commit_time=commit_time@entry=628712466364268,
> >     >>origin_id=origin_id@entry=0, origin_lsn=origin_lsn@entry=0) at
> >     >>reorderbuffer.c:1584
> 
> 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?

> > \d+ rel_having_issue
> >                                                              Table "public.rel_having_issue"
> >      Column     |           Type           | Collation | Nullable |                     Default                     | Storage  | Stats target | Description
> > ----------------+--------------------------+-----------+----------+-------------------------------------------------+----------+--------------+-------------
> >  id             | integer                  |           | not null | nextval('rel_having_issue_id_seq'::regclass) | plain    |              |
> >  field1           | character varying(255)   |           |          |                                                 | extended |              |
> >  field2          | integer                  |           |          |                                                 | plain    |              |
> >  field3 | timestamp with time zone |           |          |                                                 | plain    |              |
> > Indexes:
> >     "rel_having_issue_pkey" PRIMARY KEY, btree (id)

-- 
Álvaro Herrera                            39°49'30"S 73°17'W
<inflex> really, I see PHP as like a strange amalgamation of C, Perl, Shell
<crab> inflex: you know that "amalgam" means "mixture with mercury",
       more or less, right?
<crab> i.e., "deadly poison"