Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ifv4B-0000aU-JQ for pgsql-bugs@arkaria.postgresql.org; Sat, 14 Dec 2019 00:13:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ifv49-0001rx-Hi for pgsql-bugs@arkaria.postgresql.org; Sat, 14 Dec 2019 00:13:49 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ifv49-0001rm-7M; Sat, 14 Dec 2019 00:13:49 +0000 Received: from smtp-fw-6001.amazon.com ([52.95.48.154]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ifv41-0007os-Gd; Sat, 14 Dec 2019 00:13:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1576282422; x=1607818422; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=4P2kB8+tKLYOMeTnXsEsobIzoH36cBR5rI6H6lm/l+4=; b=qgx0FAvGmyclmsdCMiBbF0WuLXwgZjnjGYxyIFRd272687C49NcwFCD4 1jwAMuUX7OoUWO4DjNOn+ve2IWLk7XH23pYWwaab9QVG4nSulcKZYpfhL 0lNrHorAptjmMha9Xa/dqFMAD12LpjwrECWwac86MVtaX9geCaDEUeIK9 Q=; IronPort-SDR: ZeLYngJ8ODW3hGgumRG+l6B4rjLAlXkQKqGoM5p4/8FGkLALKC4nFFEatyHziP8mEDeYBe57rv gHZvl48jGk8A== X-IronPort-AV: E=Sophos;i="5.69,311,1571702400"; d="scan'208,217";a="9030868" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1e-a70de69e.us-east-1.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP; 14 Dec 2019 00:13:39 +0000 Received: from EX13MTAUWA001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1e-a70de69e.us-east-1.amazon.com (Postfix) with ESMTPS id 4D212A2A98; Sat, 14 Dec 2019 00:13:36 +0000 (UTC) Received: from EX13D18UWA002.ant.amazon.com (10.43.160.199) by EX13MTAUWA001.ant.amazon.com (10.43.160.58) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 14 Dec 2019 00:13:36 +0000 Received: from 186590ce269b.ant.amazon.com (10.43.160.100) by EX13D18UWA002.ant.amazon.com (10.43.160.199) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 14 Dec 2019 00:13:36 +0000 Subject: Re: logical decoding bug: segfault in ReorderBufferToastReplace() To: Andres Freund , "Drouvot, Bertrand" CC: Tomas Vondra , "pgsql-bugs@postgresql.org" , PostgreSQL-development References: <20191205133836.lulisfo2fphdrjp3@development> <20191211163522.t2ljtydarlmusoix@alap3.anarazel.de> From: Jeremy Schneider Message-ID: <81182626-e836-061f-8f19-204edac18922@amazon.com> Date: Fri, 13 Dec 2019 16:13:35 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191211163522.t2ljtydarlmusoix@alap3.anarazel.de> Content-Type: multipart/alternative; boundary="------------4CC362CE056568EFE0D522B1" Content-Language: en-US X-Originating-IP: [10.43.160.100] X-ClientProxiedBy: EX13D22UWB001.ant.amazon.com (10.43.161.198) To EX13D18UWA002.ant.amazon.com (10.43.160.199) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --------------4CC362CE056568EFE0D522B1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 12/11/19 08:35, Andres Freund wrote: > 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. Unfortunately the WAL logs are no longer available at this time.  :( I did a little poking around in the core file and searching source code but didn't find anything yet.  Is there any memory structure that would have the preceding/following records cached in memory?  If so then I might be able to extract this from the core dumps. > Seems like we clearly should add an elog(ERROR) here, so we error out, > rather than crash. done - in the commit that I replied to when I started this thread :) https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=69f883fef14a3fc5849126799278abcc43f40f56 > Has there been DDL to this table? I'm not sure that we will be able to find out at this point.  > Could you print out *change? This was also in the original email - here it is: (gdb) print *change $1 = {lsn = 9430473343416, action = REORDER_BUFFER_CHANGE_INSERT, origin_id = 0, data = {tp = {relnode = {spcNode = 1663, dbNode = 16401,         relNode = 16428}, clear_toast_afterwards = true, oldtuple = 0x0, newtuple = 0x2b79313f9c68}, truncate = {       nrelids = 70441758623359, cascade = 44, restart_seqs = 64, relids = 0x0}, msg = {       prefix = 0x40110000067f
, message_size = 4294983724, message = 0x0},     snapshot = 0x40110000067f, command_id = 1663, tuplecid = {node = {spcNode = 1663, dbNode = 16401, relNode = 16428}, tid = {         ip_blkid = {bi_hi = 1, bi_lo = 0}, ip_posid = 0}, cmin = 0, cmax = 826252392, combocid = 11129}}, node = {prev = 0x30ac918,     next = 0x30ac9b8}} > Is this version of postgres effectively unmodified in any potentially > relevant region (snapshot computations, generation of WAL records, ...)? It's not changed from community code in any relevant regions.  (Also, FYI, this is not Aurora.) -Jeremy -- Jeremy Schneider Database Engineer Amazon Web Services --------------4CC362CE056568EFE0D522B1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
On 12/11/19 08:35, Andres Freund wrote:
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.
Unfortunately the WAL logs are no longer available at this time.  :(

I did a little poking around in the core file and searching source code but didn't find anything yet.  Is there any memory structure that would have the preceding/following records cached in memory?  If so then I might be able to extract this from the core dumps.

Seems like we clearly should add an elog(ERROR) here, so we error out,
rather than crash.
done - in the commit that I replied to when I started this thread :)

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=69f883fef14a3fc5849126799278abcc43f40f56

Has there been DDL to this table?
I'm not sure that we will be able to find out at this point. 

Could you print out *change?

This was also in the original email - here it is:

(gdb) print *change
$1 = {lsn = 9430473343416, action = REORDER_BUFFER_CHANGE_INSERT, origin_id = 0, data = {tp = {relnode = {spcNode = 1663, dbNode = 16401,
        relNode = 16428}, clear_toast_afterwards = true, oldtuple = 0x0, newtuple = 0x2b79313f9c68}, truncate = {
      nrelids = 70441758623359, cascade = 44, restart_seqs = 64, relids = 0x0}, msg = {
      prefix = 0x40110000067f <Address 0x40110000067f out of bounds>, message_size = 4294983724, message = 0x0},
    snapshot = 0x40110000067f, command_id = 1663, tuplecid = {node = {spcNode = 1663, dbNode = 16401, relNode = 16428}, tid = {
        ip_blkid = {bi_hi = 1, bi_lo = 0}, ip_posid = 0}, cmin = 0, cmax = 826252392, combocid = 11129}}, node = {prev = 0x30ac918,
    next = 0x30ac9b8}}

Is this version of postgres effectively unmodified in any potentially
relevant region (snapshot computations, generation of WAL records, ...)?
It's not changed from community code in any relevant regions.  (Also, FYI, this is not Aurora.)

-Jeremy

-- 
Jeremy Schneider
Database Engineer
Amazon Web Services
--------------4CC362CE056568EFE0D522B1--