Re: logical decoding bug: segfault in ReorderBufferToastReplace()

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: logical decoding bug: segfault in ReorderBufferToastReplace()
Дата
Msg-id 202106050007.hygt5df5ni64@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: logical decoding bug: segfault in ReorderBufferToastReplace()  (Andres Freund <andres@anarazel.de>)
Ответы Re: logical decoding bug: segfault in ReorderBufferToastReplace()
Список pgsql-bugs
[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"



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

Предыдущее
От: "leiyanliang@highgo.com"
Дата:
Сообщение: Re: BUG #17049: what is the parameter wal_consistency_checking default value ?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17048: about trace_locks parameter problem