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 
>     >>(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=,
>     >>    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:

> 
> \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