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()
(Dilip Kumar <dilipbalaut@gmail.com>)
|
Список | 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 ?