Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oJ010-0005sa-So for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Aug 2022 22:05:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oJ001-0007m8-H2 for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Aug 2022 22:04:25 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oJ001-0007ly-3l for pgsql-hackers@lists.postgresql.org; Tue, 02 Aug 2022 22:04:25 +0000 Received: from mail-qt1-x829.google.com ([2607:f8b0:4864:20::829]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oIzzw-00056n-1o for pgsql-hackers@lists.postgresql.org; Tue, 02 Aug 2022 22:04:24 +0000 Received: by mail-qt1-x829.google.com with SMTP id l14so11398196qtv.4 for ; Tue, 02 Aug 2022 15:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc; bh=0OnYjLPrUh0W9c9f5WB3r/HMTBZ194MNIAUAxiTQQEc=; b=cFeVpg1nNxmFPuFpTj7JdRMaXQvqcQJHP2yo74Ff6YJBpt1msiGw+axYu4ECqXTrXF hFzUoM7JJyQbqTPQm9SGsShSNFKEzw48w3ZKzC7/4xHvYVE57wYbs80L2vqEQL6MyfbQ zw6N0jXjoCYezUvazFKaQwqVCPZc7YF8i+j30BX7T4CkwAiG8lU/w7om2svuOcE+ow8T ccs58dlin6RfFjtlCyHQf3ondDfUcwMMNH1VzjuahbshI9um64ElEJolId+n9k27fXA+ 43HQT5are1MsjbxtUdpd8LAq6Z+QWBaskbX12sKivwlVxWATTHR2Eyg+9Gbruu6dBXj8 h9TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=0OnYjLPrUh0W9c9f5WB3r/HMTBZ194MNIAUAxiTQQEc=; b=3umWmL3zn60+A4avbZkcRFy5a5/q+IFBy/yY1NC/4qxhU2F0Q0w0h4dLv8NUmTffHH yKVj2h+7Ue8kl55RhYHbdzgqy1TJ5B+piHhJHtba1+7SchSXYFPvWgWq83c/H+hWorOW kjv9Z6i7Tw7o04DzTrotWuvLPSNuiLK3aXIrfgP6yrhtr9uke0DasIcR9mMhyHlCqVA6 kksY2bUi6srur/BGA9nNxg/M0lGxMr7VeYnH3Ln05H3ZFHI2zvQlNr/NZcutbfEo7Evl xl6iutTPY5WKEJvg2a0gObYKE4/E491yHDjoGwoQcKF+JpjPmjUyHFEy1j2L4wix5Tt2 mYRA== X-Gm-Message-State: AJIora+FMvgCFXup4d+AT5X/ZJqNGQUKAn06/lVbcCIOo2greXtJHKUK mzfdcu2pD3C0IitSznAIsNlI5Q== X-Google-Smtp-Source: AGRyM1usXGqSSOcQoJjZFuzjdURJXJnkhlwVttac4VdDPYACTBZ/DaWD48vm9ibCppA44gWG0dBEXg== X-Received: by 2002:ac8:5846:0:b0:31e:fabb:bf53 with SMTP id h6-20020ac85846000000b0031efabbbf53mr20091552qth.353.1659477858140; Tue, 02 Aug 2022 15:04:18 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id u7-20020a05620a0c4700b006b627d42616sm11653357qki.35.2022.08.02.15.04.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Aug 2022 15:04:17 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id AC527800CA7; Tue, 2 Aug 2022 17:04:16 -0500 (CDT) Date: Tue, 2 Aug 2022 17:04:16 -0500 From: Justin Pryzby To: Tom Lane Cc: Robert Haas , Dilip Kumar , Andres Freund , Ashutosh Sharma , Maciek Sakrejda , Bruce Momjian , Alvaro Herrera , Andrew Dunstan , Heikki Linnakangas , pgsql-hackers@lists.postgresql.org Subject: Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints Message-ID: <20220802220416.GC13682@telsasoft.com> References: <20220802175043.GA13682@telsasoft.com> <2767668.1659476794@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2767668.1659476794@sss.pgh.pa.us> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Aug 02, 2022 at 05:46:34PM -0400, Tom Lane wrote: > Robert Haas writes: > > WARNING: problem in alloc set PortalContext: req size > alloc size for chunk 0x7f99508911f0 in block 0x7f9950890800 > > This looks like nothing so much as the fallout from something scribbling > past the end of an allocated palloc chunk, or perhaps writing on > already-freed space. Perhaps running the test case under valgrind > would help to finger the culprit. Yeah but my test case is so poor that it's a chore ... (Sorry for that, but it took me 2 days to be able to reproduce the problem so I sent it sooner rather than looking for a better way ... ) I got this interesting looking thing. ==11628== Invalid write of size 8 ==11628== at 0x1D12B3A: smgrsetowner (smgr.c:213) ==11628== by 0x1C7C224: RelationGetSmgr (rel.h:572) ==11628== by 0x1C7C224: RelationCopyStorageUsingBuffer (bufmgr.c:3725) ==11628== by 0x1C7C7A6: CreateAndCopyRelationData (bufmgr.c:3817) ==11628== by 0x14A4518: CreateDatabaseUsingWalLog (dbcommands.c:221) ==11628== by 0x14AB009: createdb (dbcommands.c:1393) ==11628== by 0x1D2B9AF: standard_ProcessUtility (utility.c:776) ==11628== by 0x1D2C46A: ProcessUtility (utility.c:530) ==11628== by 0x1D265F5: PortalRunUtility (pquery.c:1158) ==11628== by 0x1D27089: PortalRunMulti (pquery.c:1315) ==11628== by 0x1D27A7C: PortalRun (pquery.c:791) ==11628== by 0x1D1E33D: exec_simple_query (postgres.c:1243) ==11628== by 0x1D218BC: PostgresMain (postgres.c:4505) ==11628== Address 0x1025bc18 is 2,712 bytes inside a block of size 8,192 free'd ==11628== at 0x4033A3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==11628== by 0x217D7C2: AllocSetReset (aset.c:608) ==11628== by 0x219B57A: MemoryContextResetOnly (mcxt.c:181) ==11628== by 0x217DBD5: AllocSetDelete (aset.c:654) ==11628== by 0x219C1EC: MemoryContextDelete (mcxt.c:252) ==11628== by 0x21A109F: PortalDrop (portalmem.c:596) ==11628== by 0x21A269C: AtCleanup_Portals (portalmem.c:907) ==11628== by 0x11FEAB1: CleanupTransaction (xact.c:2890) ==11628== by 0x120A74C: AbortCurrentTransaction (xact.c:3328) ==11628== by 0x1D2158C: PostgresMain (postgres.c:4232) ==11628== by 0x1B15DB5: BackendRun (postmaster.c:4490) ==11628== by 0x1B1D799: BackendStartup (postmaster.c:4218) ==11628== Block was alloc'd at ==11628== at 0x40327F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==11628== by 0x217F0DC: AllocSetAlloc (aset.c:920) ==11628== by 0x219E4D2: palloc (mcxt.c:1082) ==11628== by 0x14A14BE: ScanSourceDatabasePgClassTuple (dbcommands.c:444) ==11628== by 0x14A1CD8: ScanSourceDatabasePgClassPage (dbcommands.c:384) ==11628== by 0x14A20BF: ScanSourceDatabasePgClass (dbcommands.c:322) ==11628== by 0x14A4348: CreateDatabaseUsingWalLog (dbcommands.c:177) ==11628== by 0x14AB009: createdb (dbcommands.c:1393) ==11628== by 0x1D2B9AF: standard_ProcessUtility (utility.c:776) ==11628== by 0x1D2C46A: ProcessUtility (utility.c:530) ==11628== by 0x1D265F5: PortalRunUtility (pquery.c:1158) ==11628== by 0x1D27089: PortalRunMulti (pquery.c:1315) -- Justin