From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Andres Freund <andres@anarazel.de>
Cc: Drouvot, Bertrand <bdrouvot@amazon.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: pgsql-bugs@postgresql.org <pgsql-bugs@postgresql.org>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Schneider (AWS), Jeremy <schnjere@amazon.com>
Subject: Re: logical decoding bug: segfault in ReorderBufferToastReplace()
Date: Fri, 4 Jun 2021 20:07:05 -0400
Message-ID: <202106050007.hygt5df5ni64@alvherre.pgsql> (raw)
In-Reply-To: <20191211163522.t2ljtydarlmusoix@alap3.anarazel.de>
[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"
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: alvherre@alvh.no-ip.org, andres@anarazel.de, bdrouvot@amazon.com, tomas.vondra@2ndquadrant.com, pgsql-hackers@postgresql.org, schnjere@amazon.com
Subject: Re: logical decoding bug: segfault in ReorderBufferToastReplace()
In-Reply-To: <202106050007.hygt5df5ni64@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox