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 1icrLC-0000Dw-Ve for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Dec 2019 13:38:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1icrLB-0001HI-Ob for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Dec 2019 13:38:45 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1icrLB-0001H9-7j for pgsql-hackers@lists.postgresql.org; Thu, 05 Dec 2019 13:38:45 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1icrL7-0003q1-Aj for pgsql-hackers@postgresql.org; Thu, 05 Dec 2019 13:38:43 +0000 Received: by mail-wr1-x443.google.com with SMTP id g17so3664194wro.2 for ; Thu, 05 Dec 2019 05:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=F8rgw7iYa3h2F5jkiWgz9Rn0b7nyrpxgNOHqFMEGFlU=; b=KfZi2bEV0SF+jPjuvr3g0dM0VzZCgzbuLoEch+BUEslQHRaAeIAyg4Mf3GNwHWeUrj 3PlJQAqFJlXEFLe2o5rhzS1sd6e5CLSIqGOzCkPm2JN+uMtb+f8JyrmEE0Lo0/CT8GJr v3gLVtpazW7kWJcdUm7xzezYpYaYg2MAYA1Il04YWmRn//jToxm8NVJl5d8NYsxCQ+GR jcy48r1W2LJNE3wM7ssvbARmD5sYssVn3mMQy7dqZwV1xIfTz/ZyHL/fYTr5eGq4ClgC kAZE0UoStn4FVIRDiMhXKseUnbernigLWUbwPneOO6krfWa4Qa7P6tm3L26dW/JOm57y IfMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=F8rgw7iYa3h2F5jkiWgz9Rn0b7nyrpxgNOHqFMEGFlU=; b=XCWcxvffrofwwYJKMtrYMWEsuIe4iIeSsz4sA/q59GSXntnd522jkBq2UzqiEVybzc FnaQ/GhRDrvQ+LZQ4nq/40W7pFiqUm+gXuxsvDQf50r6mFh6FRTMuwEauX9935BhAWFi /92r2zn+ZHXL1MboSJsYFlYSw7dpd54o0IY6jbbNEhJ03HE1Wk+aZft3A/9nAxXdJnyB gXG+ggN77IOEGPyxdnWSIUBtMS7s4nffj3EpK5aF0nZw8dZn1tYojXqHbNYlto7u7ugg 6AHCCEnkRDw5N/A0RuC+KSjMg0Zb7u1zFowN1ol0XUIL4uSDVnbGtmtL/UvG4IOahH7Y uRmQ== X-Gm-Message-State: APjAAAVfXyzPGmdlaL5KU8kS0RgfzOHsq5h333qm9HyP1HEPwk1rp2X3 QVV6lLRp+tSdjZZyo3Y6a4GITA== X-Google-Smtp-Source: APXvYqzeLeXyOZigfljMBkd+4uY0dR+nzSNctLsvYhxS1GA3riVMNNO5nTXiVMQcXTJPnd3IVhM6Lg== X-Received: by 2002:adf:f88c:: with SMTP id u12mr10721923wrp.323.1575553119667; Thu, 05 Dec 2019 05:38:39 -0800 (PST) Received: from localhost (static-84-42-175-93.net.upcbroadband.cz. [84.42.175.93]) by smtp.gmail.com with ESMTPSA id g9sm11326620wro.67.2019.12.05.05.38.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Dec 2019 05:38:38 -0800 (PST) Date: Thu, 5 Dec 2019 14:38:36 +0100 From: Tomas Vondra To: Jeremy Schneider Cc: "pgsql-bugs@postgresql.org" , PostgreSQL-development Subject: Re: logical decoding bug: segfault in ReorderBufferToastReplace() Message-ID: <20191205133836.lulisfo2fphdrjp3@development> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Dec 04, 2019 at 05:36:16PM -0800, Jeremy Schneider wrote: >On 9/8/19 14:01, Tom Lane wrote: >> Fix RelationIdGetRelation calls that weren't bothering with error checks. >> >> ... >> >> Details >> ------- >> https://git.postgresql.org/pg/commitdiff/69f883fef14a3fc5849126799278abcc43f40f56 > >We had two different databases this week (with the same schema) both >independently hit the condition of this recent commit from Tom. It's on >11.5 so we're actually segfaulting and restarting rather than just >causing the walsender process to ERROR, but regardless there's still >some underlying bug here. > >We have core files and we're still working to see if we can figure out >what's going on, but I thought I'd report now in case anyone has extra >ideas or suggestions. The segfault is on line 3034 of reorderbuffer.c. > >https://github.com/postgres/postgres/blob/REL_11_5/src/backend/replication/logical/reorderbuffer.c#L3034 > >3033 toast_rel = RelationIdGetRelation(relation->rd_rel->reltoastrelid); >3034 toast_desc = RelationGetDescr(toast_rel); > >We'll keep looking; let me know any feedback! Would love to track down >whatever bug is in the logical decoding code, if that's what it is. > >========== > >backtrace showing the call stack... > >Core was generated by `postgres: walsender >(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=, > commit_time=commit_time@entry=628712466364268, >origin_id=origin_id@entry=0, origin_lsn=origin_lsn@entry=0) at >reorderbuffer.c:1584 >#2 0x0000000000716248 in DecodeCommit (xid=1358809, >parsed=0x7ffc4ce123f0, buf=0x7ffc4ce125b0, ctx=0x3068f70) at decode.c:637 >#3 DecodeXactOp (ctx=0x3068f70, buf=buf@entry=0x7ffc4ce125b0) at >decode.c:245 >#4 0x000000000071655a in LogicalDecodingProcessRecord (ctx=0x3068f70, >record=0x3069208) at decode.c:117 >#5 0x0000000000727150 in XLogSendLogical () at walsender.c:2886 >#6 0x0000000000729192 in WalSndLoop (send_data=send_data@entry=0x7270f0 >) at walsender.c:2249 >#7 0x0000000000729f91 in StartLogicalReplication (cmd=0x30485a0) at >walsender.c:1111 >#8 exec_replication_command ( > cmd_string=cmd_string@entry=0x2f968b0 "START_REPLICATION SLOT >\"\" LOGICAL 893/38002B98 (proto_version '1', >publication_names '\"\"')") at walsender.c:1628 >#9 0x000000000076e939 in PostgresMain (argc=, >argv=argv@entry=0x2fea168, dbname=0x2fea020 "", > username=) at postgres.c:4182 >#10 0x00000000004bdcb5 in BackendRun (port=0x2fdec50) at postmaster.c:4410 >#11 BackendStartup (port=0x2fdec50) at postmaster.c:4082 >#12 ServerLoop () at postmaster.c:1759 >#13 0x00000000007062f9 in PostmasterMain (argc=argc@entry=7, >argv=argv@entry=0x2f92540) at postmaster.c:1432 >#14 0x00000000004be73b in main (argc=7, argv=0x2f92540) at main.c:228 > >========== > >Some additional context... > ># select * from pg_publication_rel; > prpubid | prrelid >---------+--------- > 71417 | 16453 > 71417 | 54949 >(2 rows) > >(gdb) print toast_rel >$4 = (struct RelationData *) 0x0 > >(gdb) print *relation->rd_rel >$11 = {relname = {data = "", '\000' }, >relnamespace = 16402, reltype = 16430, reloftype = 0, >relowner = 16393, relam = 0, relfilenode = 16428, reltablespace = 0, >relpages = 0, reltuples = 0, relallvisible = 0, reltoastrelid = 0, Hmmm, so reltoastrelid = 0, i.e. the relation does not have a TOAST relation. Yet we're calling ReorderBufferToastReplace on the decoded record ... interesting. Can you share structure of the relation causing the issue? regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services