Re: logical decoding bug: segfault in ReorderBufferToastReplace()

[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(at)entry=1358809,
> > >>commit_lsn=9430473346032, end_lsn=<optimized out>,
> > >> commit_time=commit_time(at)entry=628712466364268,
> > >>origin_id=origin_id(at)entry=0, origin_lsn=origin_lsn(at)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"