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 1lvjl4-0001UZ-AS for pgsql-bugs@arkaria.postgresql.org; Tue, 22 Jun 2021 17:00:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lvjl2-0005Aa-25 for pgsql-bugs@arkaria.postgresql.org; Tue, 22 Jun 2021 17:00:16 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lvjl1-0005AR-7L for pgsql-bugs@lists.postgresql.org; Tue, 22 Jun 2021 17:00:15 +0000 Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lvjkv-0005tC-8o for pgsql-bugs@lists.postgresql.org; Tue, 22 Jun 2021 17:00:14 +0000 Received: by mail-lf1-x12b.google.com with SMTP id u13so17778021lfk.2 for ; Tue, 22 Jun 2021 10:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=nGOsoEAYMcGTYfPLy8tIA1cAIkrKX0rpDXUlCIlqE3E=; b=XClC/m9+zdY5CJr1wJyWvlLUptFMaaE+9dsE3Ybk4GKfJmoW973yqYjAq7kBgf6hyK QYnv691kPxS6LrHyBNc6km7BOyTpQjQHy16SpjVP9UEOoDPoGDC7vjzzFhQCvhefghLb /FqjKZSgnngi0jwL4WQUY9nXpIlw41Yh7jq/AwKh8d0zON7lx/mL8smuN1kvGxZbocSM rcZpLKPkHZ7GRidVR9jqE2V+CmWRGRiBuZb+bGTsF25aWx/DS+RjqO4z5AKqf6ytywdx xy7ASqqOXa0bhD7WZ6o+UiqEC5+TunguPC1Y7k2AXNaK8NZFDatjLpb5kjVAdP2V5TTx Oibw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=nGOsoEAYMcGTYfPLy8tIA1cAIkrKX0rpDXUlCIlqE3E=; b=uKHBm0uMr8wrQu9IIJ3wkT663+XEBgmeo5NmKb/jTLuVFBHdL9bn8hv4Q3IgE7GpEq xDCZUV7V1Kn9g5xBC/h7G15x+GUrzhu0+Tbiuy2qBw5fRm98nseayz207ncF4zS97rkJ D7noG1dJwrwwV3R2G5tVcj5NAhDdV1hFtfIzTaG7Tdjx8yXsRSXePSInwbo5iJoZ5EuL aLvlnc1zjMaR8soj7NYfYxAK2KsatvixdLI/hk/X3BNoPEqxm8khio3MdFNAdjUSz87N /4jU0rbBkFc9yalCkBghq0io8pLoEucFmnrLef6UEpSvn+DX2WZy2ddF51ylUFiODIo6 8Eaw== X-Gm-Message-State: AOAM532WVVY+wTRBvQbgi0pVI5Mo8xRXbBVvYjsE2mmaJsOGMd6Z4ty+ RZ3IVPP4HWDHNVS7HwSDh+YyEmaDmoA= X-Google-Smtp-Source: ABdhPJwKsRBvKXCFhksTZBTU9+oDg7Rg2CuusY/kK++YtZ3uar6a9MVNtd0DSXs7fgHX9xM2tsjMcA== X-Received: by 2002:ac2:4294:: with SMTP id m20mr3640222lfh.6.1624381206577; Tue, 22 Jun 2021 10:00:06 -0700 (PDT) Received: from [1.0.0.7] ([178.155.6.177]) by smtp.gmail.com with ESMTPSA id k3sm2662841ljm.5.2021.06.22.10.00.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Jun 2021 10:00:06 -0700 (PDT) Subject: Re: BUG #17064: Parallel VACUUM operations cause the error "global/pg_filenode.map contains incorrect checksum" To: Thomas Munro , Heikki Linnakangas Cc: PostgreSQL mailing lists References: <17064-bb0d7904ef72add3@postgresql.org> From: Alexander Lakhin Message-ID: <11523fe8-7614-9d57-1ad5-c12a4c4ec9cf@gmail.com> Date: Tue, 22 Jun 2021 20:00:04 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello, 22.06.2021 16:00, Thomas Munro wrote: > On Tue, Jun 22, 2021 at 9:30 PM Heikki Linnakangas wrote: >> Hmm, the simplest explanation would be that the read() or write() on the >> relmapper file is not atomic. We assume that it is, and don't use a lock >> in load_relmap_file() because of that. Is there anything unusual about >> the filesystem, mount options or the kernel you're using? I could not >> reproduce this on my laptop. Does the attached patch fix it for you? > I have managed to reproduce this twice on a laptop running Linux > 5.10.0-2-amd64, after trying many things for several hours. Both > times I was using ext4 in a loopback file (underlying is xfs, I had no > luck there hence hunch that I should try ext4, may not be significant > though) with fsync=off (ditto). I'm sorry, I forgot that I've set "fsync=off" in my postgresql.conf (to avoid NVME-specific slowdown on fsyncs). It really does matter. With fsync=on the demo script passes 20 iterations successfully. I reproduce the issue on Ubuntu 20.04 with the kernel 5.9.15, ext4 (without any specific options) on NVME storage, and Ryzen 3700x. It was first encountered on Debian 10 with the kernel 4.19.0, ext4 on software RAID built on NVME storage too, and Xeon 5220. The attached patch fixes it for me (with fsync=off). 3 runs by 20 iterations completed without the error (without the patch I get the error on the first iteration). Best regards, Alexander