Re: logical decoding bug: segfault in ReorderBufferToastReplace()

Hi,

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:

>
> \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)
>
> select relname,relfilenode,reltoastrelid from pg_class where relname='rel_having_issue';
> relname | relfilenode | reltoastrelid
> ---------------------+-------------+---------------
> rel_having_issue | 16428 | 0

I think we need to see pg_waldump output for the preceding records. That
might allow us to see why there's a toast record that's being associated
with this table, despite there not being a toast table.

Seems like we clearly should add an elog(ERROR) here, so we error out,
rather than crash.

Has there been DDL to this table?

Could you print out *change?

Is this version of postgres effectively unmodified in any potentially
relevant region (snapshot computations, generation of WAL records, ...)?

Greetings,

Andres Freund