Re: logical decoding bug: segfault in ReorderBufferToastReplace()

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: logical decoding bug: segfault in ReorderBufferToastReplace()
Дата
Msg-id 20191211163522.t2ljtydarlmusoix@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: logical decoding bug: segfault in ReorderBufferToastReplace()  ("Drouvot, Bertrand" <bdrouvot@amazon.com>)
Ответы Re: logical decoding bug: segfault in ReorderBufferToastReplace()  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: logical decoding bug: segfault in ReorderBufferToastReplace()  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: logical decoding bug: segfault in ReorderBufferToastReplace()  (Jeremy Schneider <schnjere@amazon.com>)
Re: logical decoding bug: segfault in ReorderBufferToastReplace()  (Jeremy Schneider <schnjere@amazon.com>)
Re: logical decoding bug: segfault in ReorderBufferToastReplace()  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-bugs
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@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:

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



В списке pgsql-bugs по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #16160: Minor memory leak in case of starting postgres server with SSL encryption
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Memory leak (possibly connected to postgis) leading to server crash