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 1hlpha-0000w3-HZ for pgsql-hackers@arkaria.postgresql.org; Fri, 12 Jul 2019 07:10:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hlphZ-0006hl-9e for pgsql-hackers@arkaria.postgresql.org; Fri, 12 Jul 2019 07:10:41 +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 1hlphY-0006he-Uo for pgsql-hackers@lists.postgresql.org; Fri, 12 Jul 2019 07:10:41 +0000 Received: from mail-pg1-x52f.google.com ([2607:f8b0:4864:20::52f]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hlphW-0006mk-HI for pgsql-hackers@postgresql.org; Fri, 12 Jul 2019 07:10:40 +0000 Received: by mail-pg1-x52f.google.com with SMTP id g15so4126526pgi.4 for ; Fri, 12 Jul 2019 00:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:message-id:to:cc:subject:from:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=rce0DETGrMBtCFLIfaUWmTbLF9TxJbknjWnDqH+4US4=; b=Qr/WV+TWoEFyv8jU+NShSLN+6nm9ddCUHdOtRVx1EGFVyjpQ6lmr+crgFrC68C38AY bYrPS0+orj765/wVstDhKrPpg0KtO6QRFgosayP0iOZql7xU2kwz/0lqOP26pEUGo/p7 JYYmusdaUTRBSW9TkLc0udZiVjohRQIcigrjcUkhl2lhBhaQfh4zVsQahCR8RMTk8eKC Ie/AgZqJZOgKlYhd5HONrUr5DG2W2tRzBMbS+OQCQvZfcZUh9swqkW/ksjEkrtQccA+b ztzrhDh8FpbbbP5YJIL1WnLN2VdsLd2f/KLYxVOiSf0HLjZocKdH4ZhPARTkkNZqlYI+ BsLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:to:cc:subject:from:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=rce0DETGrMBtCFLIfaUWmTbLF9TxJbknjWnDqH+4US4=; b=tsK78Hi/NSOLRh2kZRZvOIJBkw3l+TkNdAKmXKZP8CBxM0wWU0ua8ig+Ecogog3Lbq O8s4RUt3p45OGgquBNkNIx4bGYxRUdL0U7RgJQU3j0ItK8QmhpPZD1cl7jUptGETYP78 y+MCdbQVC/OKDCqtvkKbCsBHEci4kzaG7mf38/3QoqcY+O4C43WY4tyqZGbcmDO7jSlj ZTeeJ1VnEkzE87aYPHG+dugT0DHdyTJHcHvIEBmcJvfYWNK+JldxvOLm/OZ3n/BWUb2j ozqKwBxu+I9zB8X/jBu4PDh96HG/QhEYwERE+75H5TKa2E13E5e9JAt/XeKxyTBWyPpQ fNfw== X-Gm-Message-State: APjAAAXxZ9nGREAmoSt00k5V1wf56HfO7vCVzhsJkm8yF9cyfwwZmUQ1 3qyyLdaxhOI9+D2xJt4ufxc= X-Google-Smtp-Source: APXvYqyCgSU18a1Q6qG6AxUhDMjp43ZV/bdoVAIUHMfT0ZceIXRq8Ci+1d/R+oJhoX2rKZ+7tgiZCg== X-Received: by 2002:a63:f959:: with SMTP id q25mr8981022pgk.357.1562915436041; Fri, 12 Jul 2019 00:10:36 -0700 (PDT) Received: from localhost (w204169.dynamic.ppp.asahi-net.or.jp. [121.1.204.169]) by smtp.gmail.com with ESMTPSA id j6sm7674615pjd.19.2019.07.12.00.10.34 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 12 Jul 2019 00:10:35 -0700 (PDT) Date: Fri, 12 Jul 2019 16:10:16 +0900 (Tokyo Standard Time) Message-Id: <20190712.161016.56338282.horikyota.ntt@gmail.com> To: andres@anarazel.de Cc: pgsql-hackers@postgresql.org Subject: Re: Remove page-read callback from XLogReaderState. From: Kyotaro Horiguchi In-Reply-To: <20190528114524.dvj6ymap2virlzro@alap3.anarazel.de> References: <20190418.210257.43726183.horiguchi.kyotaro@lab.ntt.co.jp> <20190528114524.dvj6ymap2virlzro@alap3.anarazel.de> User-Agent: Mew version 6.5 on Emacs 22.2 / Mule 5.0 =?iso-2022-jp?B?KBskQjpnGyhCKQ==?= / Meadow-3.01-dev (TSUBO-SUMIRE) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk At Tue, 28 May 2019 04:45:24 -0700, Andres Freund wrote in <20190528114524.dvj6ymap2virlzro@alap3.anarazel.de> > Hi, > > On 2019-04-18 21:02:57 +0900, Kyotaro HORIGUCHI wrote: > > Hello. As mentioned before [1], read_page callback in > > XLogReaderState is a cause of headaches. Adding another > > remote-controlling stuff to xlog readers makes things messier [2]. > > > > I refactored XLOG reading functions so that we don't need the > > callback. In short, ReadRecrod now calls XLogPageRead directly > > with the attached patch set. > > > > | while (XLogReadRecord(xlogreader, RecPtr, &record, &errormsg) > > | == XLREAD_NEED_DATA) > > | XLogPageRead(xlogreader, fetching_ckpt, emode, randAccess); > > > > On the other hand, XLogReadRecord became a bit complex. The patch > > makes XLogReadRecord a state machine. I'm not confident that the > > additional complexity is worth doing. Anyway I'll gegister this > > to the next CF. > > Just FYI, to me this doesn't clearly enough look like an improvement, > for a change of this size. Thanks for the opiniton. I kinda agree about size but it is a decision between "having multiple callbacks called under the hood" vs "just calling a series of functions". I think the patched XlogReadRecord is easy to use in many situations. It would be better if I could completely refactor the function without the syntax tricks but I think the current patch is still smaller and clearer than overhauling it. If many of the folks think that adding a callback is better than this refactoring, I will withdraw this.. reagrds. -- Kyotaro Horiguchi NTT Open Source Software Center