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 1iZYFh-0000jq-0i for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Nov 2019 10:39:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iZYFf-0008Td-23 for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Nov 2019 10:39:23 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iZYFe-0008TW-G9 for pgsql-hackers@lists.postgresql.org; Tue, 26 Nov 2019 10:39:22 +0000 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iZYFb-0000OL-8j for pgsql-hackers@postgresql.org; Tue, 26 Nov 2019 10:39:21 +0000 Received: by mail-wm1-x344.google.com with SMTP id g206so2642542wme.1 for ; Tue, 26 Nov 2019 02:39:18 -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 :content-id:date:message-id; bh=I0k39TfXRRDcxmRG0ButlCeIiU39vJ2WDA608mUi7g8=; b=typ6Y5np0+V9nBDnjdq0I4V61duyTtm0swclL78SAwLkgiWS159foM9TVsIr3qRm22 DwMwtzMHbjYPOG3MLfrebp7f8YUddOvLrViEQnyEcWgLsYymsRUFi+Ug0oa/O1zgcuB1 m7gq8K8cl/0554IwcygdRjS3e15QmKqn/WsB+2i+F6VT4cKej7abWh1Z3n4QWc0snHba HjDMsAcT5rLO9RcmkomTte6Fz9x/LV51uFjD21mB0wl6He1F8Z4QxZ9c3rCOMHGonvb7 5Tk5ZcQNYDvP7JaDyA8mGa5LZMXA9t5TWXzP/O3wrbR1DZT4NrY84xQY1lpWPlR2L301 7LZA== 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:content-id:date:message-id; bh=I0k39TfXRRDcxmRG0ButlCeIiU39vJ2WDA608mUi7g8=; b=nDeF4ZhnzB+KG/jSOCchLVJ8DqcIatDXEDQSncsOpdz2zVl984J3Zl1auChVFoTbqU maqOP2AXdz2LkFmDV+snPNPfefLwFRduXFoQq1MNVGzji0N+wjyRweH8EOGl+IzbIbHu ck5RgW+NWznVnHj8xPB6ywtv9v3e8ySP2GnImMlwR+ewuNZ6+jUr96vc5wUaHNNStaK3 RA7+5W5h9GkqU3sLS04NphrDEu656kbughc7sLiw2wytpktNoqprU0Xo2JaFDFzOuszS WNk8juFQ0Hu5yClriZ3PAB0GC+FTPNpAGdAu/M2II3ciKalw0NtzNYJmrsdxt4NuW7pY bmmg== X-Gm-Message-State: APjAAAX7WywnyA/WhW7XxREMQLCuLUjf5Ew1ZvVd7DK4roF5+u7CW+iA gLdBhS/Z0GRY8GSokErmQpAV8w== X-Google-Smtp-Source: APXvYqw9qQ1SADTf+h33X42rUuulcsw06M3voB1266QoOZdUMsy4CCFEHzShMn6dn6YYpZ2lhro1lQ== X-Received: by 2002:a7b:c934:: with SMTP id h20mr3461741wml.56.1574764757541; Tue, 26 Nov 2019 02:39:17 -0800 (PST) Received: from antos ([77.87.240.5]) by smtp.gmail.com with ESMTPSA id f67sm2654272wme.16.2019.11.26.02.39.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Nov 2019 02:39:16 -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: <20191125181534.GA19210@alvherre.pgsql> References: <20191125181534.GA19210@alvherre.pgsql> Comments: In-reply-to Alvaro Herrera message dated "Mon, 25 Nov 2019 15:15:34 -0300." X-Mailer: MH-E 8.6+git; nmh 1.7; GNU Emacs 26.2.50 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <66133.1574764817.1@antos> Date: Tue, 26 Nov 2019 11:40:17 +0100 Message-ID: <66134.1574764817@antos> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Alvaro Herrera wrote: > On 2019-Nov-25, Antonin Houska wrote: > > > Alvaro Herrera wrote: > > > > 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. > > Excellent, I pushed it with this change included and some other cosmetic > changes. Thanks! > Now there's only XLogPageRead() ... Hm, this seems rather specific, not sure it's worth trying to use WALRead() here. Anyway, I notice that it uses pg_read() too. > > I'd appreciate more background about the "partial read" that > > Michael mentions here: > > > > https://www.postgresql.org/message-id/20191125033048.GG37821%40paquier.xyz > > In the current implementation, if pg_pread() does a partial read, we > just loop one more time. > > I considered changing the "if (readbytes <= 0)" with "if (readbytes < > segbytes)", but that seemed pointless. In the pread() documentation I see "Upon reading end-of-file, zero is returned." but that does not tell whether zero can be returned without reaching EOF. However XLogPageRead() handles zero as an error, so WALRead() is consistent with that. > However, writing this now makes me think that we should add a > CHECK_FOR_INTERRUPTS in this loop. (I also wonder if we shouldn't limit > the number of times we retry if pg_pread returns zero (i.e. no error, > but no bytes read either). I don't know if this is a real-world > consideration.) If statement above is correct, then we shouldn't need this. -- Antonin Houska Web: https://www.cybertec-postgresql.com