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 1iZAF2-0002FM-Cz for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Nov 2019 09:01:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iZAF0-0001cN-VV for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Nov 2019 09:01:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iZAF0-0001cG-Gr for pgsql-hackers@lists.postgresql.org; Mon, 25 Nov 2019 09:01:06 +0000 Received: from mail-wm1-x342.google.com ([2a00:1450:4864:20::342]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iZAEw-00085v-Eg for pgsql-hackers@postgresql.org; Mon, 25 Nov 2019 09:01:05 +0000 Received: by mail-wm1-x342.google.com with SMTP id l1so14503879wme.2 for ; Mon, 25 Nov 2019 01:01:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:in-reply-to:references:comments:mime-version :date:message-id; bh=7tInp6jzUAyHFJuOWthpyuK4rqLIHvBgteZwLQLFJbI=; b=ioF9o2xdmwg2nOSTljlZzXUtBEg1G/3zhj864e8nTPvfOSQ1LumHPBlCod3tbxXFh1 m1VWUrwTIJySifBzAUrJgaBzlt5KwHbK9TSV7KwdfrqjPzGyCTimtsuUgs6kebJ4QOOA Y5fAMwtj8Slenhno200xkdbsP2h6ua3zpAA02CxHNRYW15M3ZsRenYSNrSU/dPK0+lBE QXe+TXJ7ZDPV/7WDN1Ahqv+ySG4VF2jHuaFCkOSA9aS4MDc/NGXqdDOK4csFdi6DM1RC 2nr+MYlqN9l0dtEIxtJL8WCpJ5fuBnF/B3SRsyyGiBar09ew9ieqRNQqxTwk9tfx0DeY gXJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :comments:mime-version:date:message-id; bh=7tInp6jzUAyHFJuOWthpyuK4rqLIHvBgteZwLQLFJbI=; b=a4ryj7MjJa30w+KPLkZJ5qHOP0qPjwKlhq5pdAOKckjWzQhAH1UYPGLuNwJ+K066ym oynk/60wIDSWyKow0BuaLKai98pzsNlo/4A9NjrNpW0DWuIszmwz2AuWPNVo0t2lqqZ6 RZLa/FbXKWgpl4pe63UIl4WpOz/Jih669kYSPvthKxaka54rV2bHvv75AiwJadlDAK+a sQoK4iGJ5RZFCMgopuqPWBWdLfq5HogNL3u4mN8tjTdPbLYRBrnND997xYNehpluF9w0 SzXgr0VCksc9y90WyJI85mI6uWVwfOGmE8TY5y02Rzh375cxKKr7YhXFP/OGheJMEALD lckA== X-Gm-Message-State: APjAAAXWh2iM9b1cLiAkliup1EzKMrxbz2DDl89WfsC1+JUQMrv3cxYg RO5EgWMiX+UcpAvvbzTVdm5Ksw== X-Google-Smtp-Source: APXvYqyxU7CUVWxuKdCum9cF2GEc61bEutrC947ivpocyg3PrwoLmKw8ksxENCwMZ6iIxDqs2FVFmA== X-Received: by 2002:a7b:cb4a:: with SMTP id v10mr26601253wmj.106.1574672460974; Mon, 25 Nov 2019 01:01:00 -0800 (PST) Received: from antos ([77.87.240.5]) by smtp.gmail.com with ESMTPSA id s82sm7847536wms.28.2019.11.25.01.00.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Nov 2019 01:01:00 -0800 (PST) From: Antonin Houska To: Alvaro Herrera cc: Michael Paquier , Thomas Munro , Robert Haas , "pgsql-hackers@postgresql.org" Subject: Re: Attempt to consolidate reading of XLOG page In-reply-to: <20191122225632.GA9169@alvherre.pgsql> References: <20191122225632.GA9169@alvherre.pgsql> Comments: In-reply-to Alvaro Herrera message dated "Fri, 22 Nov 2019 19:56:32 -0300." X-Mailer: MH-E 8.6+git; nmh 1.7; GNU Emacs 26.2.50 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Date: Mon, 25 Nov 2019 10:02:00 +0100 Message-ID: <50470.1574672520@antos> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --=-=-= Content-Type: text/plain Alvaro Herrera wrote: > On 2019-Nov-22, Antonin Houska wrote: > > > As I pointed out in > > > > https://www.postgresql.org/message-id/88183.1574261429%40antos > > > > seg.ws_off only replaced readOff in XLogReaderState. So we should only update > > ws_off where readOff was updated before commit 709d003. This does happen in > > ReadPageInternal (see HEAD) and I see no reason for the final patch to update > > ws_off anywhere else. > > Oh you're right. > > I see no reason to leave ws_off. We can move that to XLogReaderState; I > did that here. We also need the offset in WALReadError, though, so I > added it there too. Conceptually it seems clearer to me this way. > > What do you think of the attached? It looks good to me. Attached is just a fix of a minor problem in error reporting that Michael pointed out earlier. > BTW I'm not clear what errors can pread()/pg_pread() report that do not > set errno. I think lines 1083/1084 of WALRead are spurious now. All I can say is that the existing calls of pg_pread() do not clear errno, so you may be right. I'd appreciate more background about the "partial read" that Michael mentions here: https://www.postgresql.org/message-id/20191125033048.GG37821%40paquier.xyz -- Antonin Houska Web: https://www.cybertec-postgresql.com --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=wal_read_errno.patch diff --git a/src/bin/pg_waldump/pg_waldump.c b/src/bin/pg_waldump/pg_waldump.c index 04124bc254..eda81c1df1 100644 --- a/src/bin/pg_waldump/pg_waldump.c +++ b/src/bin/pg_waldump/pg_waldump.c @@ -354,9 +354,11 @@ WALDumpReadPage(XLogReaderState *state, XLogRecPtr targetPagePtr, int reqLen, state->segcxt.ws_segsize); if (errinfo.wre_errno != 0) - fatal_error("could not read in file %s, offset %u, length %zu: %s", - fname, errinfo.wre_off, (Size) errinfo.wre_req, - strerror(errinfo.wre_errno)); + { + errno = errinfo.wre_errno; + fatal_error("could not read in file %s, offset %u, length %zu: %m", + fname, errinfo.wre_off, (Size) errinfo.wre_req); + } else fatal_error("could not read in file %s, offset %u: length: %zu", fname, errinfo.wre_off, (Size) errinfo.wre_req); --=-=-=--