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 1nAkdb-00036C-Ed for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Jan 2022 03:30:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nAkda-00018e-0P for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Jan 2022 03:30:54 +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 1nAkdZ-00018V-FS for pgsql-hackers@lists.postgresql.org; Fri, 21 Jan 2022 03:30:53 +0000 Received: from mail-ot1-x32e.google.com ([2607:f8b0:4864:20::32e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nAkdS-00064V-I6 for pgsql-hackers@postgresql.org; Fri, 21 Jan 2022 03:30:52 +0000 Received: by mail-ot1-x32e.google.com with SMTP id v8-20020a9d6048000000b005960952c694so10178692otj.12 for ; Thu, 20 Jan 2022 19:30:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=/OEhNKjASsSWLZ32Tm0BbXecsI2+xFkNm0YfPJKaDC4=; b=ZmG/Mr3Ewe/UInlXLpUBD6xcdhDo9TW8RZ7FOIhvIzRaqPmbd8UoGH7qrW12+G8788 nY+veW1IspkiEbB/bxMAvCo4rAeuPdvZSDgQ56ik5dSeHCKTGwTQaBX3Uw9AalKKp1nc ZefFhchpT+CKOqBIl1gVgUNVVS38L+boLbs5A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=/OEhNKjASsSWLZ32Tm0BbXecsI2+xFkNm0YfPJKaDC4=; b=GCovBtJrl/Hq0eEq2VDLlZN1RJUl3ZRdcRnWw3xpKXjhbCGFI8X2X0uO0C2Fk+bcGO y0zJoBadPSNbtcgdj48XL6qBVvMvlEc/uzEQq0yikos3AcxEthkha9z7sYy0Cj5knabx yZKHgxR2q1yE1jeQmmnJhfvm1JfhYHZdcyeo1YqnixrV0lw98sIlOtHENh/QT+LaJrja kMBHGeo4mIfTgzYiofwAysN0hwAPuFsvLKaCbEcYFMbeZp5EyhRGWUUBeI7HVhUt9GI1 gv8dXoKYQpfykL7RiR0aX+TG8hdLMqB6sgJk6j49t4QzjLuFpqOicui8Oo/VffoWG+cK V5KQ== X-Gm-Message-State: AOAM5336RcdEX3uJZj+462fI6lldo8YKqyKjNiSD2+a4z1ZVlBJu4XU3 9rPDuBgzJPrPmJHGR5Wm4dplfA== X-Google-Smtp-Source: ABdhPJzfJ5PoKR17Jnm7C6j1jE9laaeJPhw+6q6qKBfy2G2ZoGNBv2muOia9lEI9mZ8SqPMIVZgr+w== X-Received: by 2002:a9d:7752:: with SMTP id t18mr1438206otl.243.1642735845786; Thu, 20 Jan 2022 19:30:45 -0800 (PST) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id i13sm505050otl.46.2022.01.20.19.30.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jan 2022 19:30:44 -0800 (PST) Date: Thu, 20 Jan 2022 19:30:42 -0800 From: Noah Misch To: Thomas Munro Cc: pgbf@twiska.com, Tom Lane , Michael Paquier , pgsql-hackers Subject: Re: XLogReadRecord() error in XlogReadTwoPhaseData() Message-ID: <20220121033042.GA903845@rfd.leadboat.com> References: <20211107013157.GB790288@rfd.leadboat.com> <20211112012234.GA1020314@rfd.leadboat.com> <2782601.1637189230@sss.pgh.pa.us> <20211118070506.GA1294133@rfd.leadboat.com> <20211120051823.GA1367142@rfd.leadboat.com> <20220116071210.GA735692@rfd.leadboat.com> <20220116210241.GC756210@rfd.leadboat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Jan 21, 2022 at 08:34:22AM +1300, Thomas Munro wrote: > On Mon, Jan 17, 2022 at 10:02 AM Noah Misch wrote: > > - Report a Debian bug for the sparc64+ext4 zeros problem. > > I suspect that 027_stream_regress.pl hits this kernel bug with high > probability[1]. I wonder if the owner of kittiwake and tadarida would > consider setting up an xfs file system? Or alternatively, since ext4 > didn't support concurrent writes until recently, I wonder if there is > an option somewhere to turn the new concurrency stuff off, or failing > that, if we could temporarily downgrade the kernel to an older version > that does inode-level read/write locking. If the write-only-new-bytes approach works, I think we'd want to revert those changes. Perhaps a cheaper stopgap is to make the affected tests skip on sparc Linux. Is that worth doing? (Could even limit the skip to ext4, e.g. by testing "df -x ext4 . >/dev/null".) > [1] https://www.postgresql.org/message-id/CA%2BhUKG%2BeuZ%3Ddc27ZB%3Ds74x0q%3DzU%3D2%3Dvs8%2B6TkJoTUiCPUd2dQA%40mail.gmail.com