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 1lvt7a-0004Z5-JC for pgsql-bugs@arkaria.postgresql.org; Wed, 23 Jun 2021 03:00:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lvt7Z-0007VI-Cu for pgsql-bugs@arkaria.postgresql.org; Wed, 23 Jun 2021 03:00:09 +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 1lvt7Z-0007V9-3v for pgsql-bugs@lists.postgresql.org; Wed, 23 Jun 2021 03:00:09 +0000 Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lvt7V-0002E1-SL for pgsql-bugs@lists.postgresql.org; Wed, 23 Jun 2021 03:00:08 +0000 Received: by mail-lj1-x22a.google.com with SMTP id k8so923220lja.4 for ; Tue, 22 Jun 2021 20:00:05 -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=RR4ss9v2CPO4s+vfVAfcAIGugSuSCcV1pLtcBr3Vysg=; b=Qo87GM5RDE2DIl87WRfa1UtAv58djTkv2MDHsajUorfDVzRyS/yVFfDY/wNoKxg0Z/ 9Jg6/oqThl1HsAYsubdgXfVlB3BqvvOj4dZ2WrcRtsde+dlKW4chNhmYFHvUkFV3fMC3 Qg7jD2zhQCibb3w0ycm6JG92sBjJW7dKlKKwj5LlMYpl0JaGRF8qlwQwHIWCx9AR0EKG Avi5EKp9I3hWJQSoOovXVJINB8DjgExRFustO1fe2G+rhtlMOXh/Q87yUyS3/XO9zq4u 6SGLX6JHPLi5SdFRsvkB3WVf1i1cb9+xjU6X4DOt8qTBrVpPxf1ecpCdlWlHb80QF3Bf QEqQ== 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=RR4ss9v2CPO4s+vfVAfcAIGugSuSCcV1pLtcBr3Vysg=; b=JxPxFUbESI7ivmstl9v11KQqRQ6bEOVGp0gURKL+yK15IrJgy4EXqOSsieSK3ahkrR cT14QMaUILq/ykgtV2ENEeua+5thQsIffq/jtRZAhC48Pyw3nI1bDK4IEXVVAZTLkqTN F0Al2o0mzglpWX9Q349MRiSgPAg8FOT9iei8x3z9oWHMmq6Fdu2DWCpeyV0EGFVbAxjE ktZpmJ9maRavSDoSx5Kyo8RzHOY5nleMZUZXp/uKhNvA94RiRNzVIyNlWuAPyxuIP3oD J78Stv8/slHHs39cf2utf3ZVPDp+OrQ39VVyTlXPt2fCInPV+1fgRyb7zBLn/OVsI/L4 O3Ug== X-Gm-Message-State: AOAM531Mii1B2LOQ0kRFRUcTDRfPgCaiJHLjiegXg3TPn3TGpGy5+b6k 8FtUVEHjYDo0pGmrelcGywFerC1uOq7gSA== X-Google-Smtp-Source: ABdhPJw8ru71vluXfmJYRhariDM3SSY0Y0YYq/LnJ1mCh68k65trirGV/6V7UzQaVAh+TrzvG0t1Fw== X-Received: by 2002:a2e:8953:: with SMTP id b19mr5939027ljk.242.1624417202672; Tue, 22 Jun 2021 20:00:02 -0700 (PDT) Received: from [1.0.0.7] ([178.155.6.177]) by smtp.gmail.com with ESMTPSA id j16sm146037ljh.66.2021.06.22.20.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Jun 2021 20:00:02 -0700 (PDT) Subject: Re: BUG #17064: Parallel VACUUM operations cause the error "global/pg_filenode.map contains incorrect checksum" To: Thomas Munro , Tom Lane Cc: Heikki Linnakangas , PostgreSQL mailing lists References: <17064-bb0d7904ef72add3@postgresql.org> <1715251.1624371066@sss.pgh.pa.us> From: Alexander Lakhin Message-ID: Date: Wed, 23 Jun 2021 06:00:01 +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: ru-RU List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 23.06.2021 05:29, Thomas Munro wrote: > On Wed, Jun 23, 2021 at 12:50 PM Thomas Munro wrote: >> repro > Here's a quick-and-dirty repro -- just touch test-file and then run > it. It fails about 0.1% of its read loops on ext4, for me, but > outputs nothing on other file systems and OSes I tried (XFS, FBSD UFS, > APFS). Seems a bit like there is a tendency for 64 byte (cache line?) > granularity in the mashed data it prints out. Yes, this repro fails for me too (on ext4). 11111111111111111111111111111111222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222 11111111111111111111111111111111111111111111111111111111111111111111111111111111222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222221111111111111111111111111111111122222222222222222222222222222222111111111111111111111111111111112222222222222222222222222222222211111111111111111111111111111111222222222222222222222222222222222222222222222222 11111111111111111111111111111111111111111111111111111111111111112222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222 But granularity is 16-byte. (I've seen the fail count 19763 out of 1000000 loops.) Best regards, Alexander