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 1iECKN-000332-4a for pgsql-hackers@arkaria.postgresql.org; Sat, 28 Sep 2019 12:59:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iECKJ-0005hx-Mo for pgsql-hackers@arkaria.postgresql.org; Sat, 28 Sep 2019 12:59:55 +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 1iECKJ-0005hG-9W for pgsql-hackers@lists.postgresql.org; Sat, 28 Sep 2019 12:59:55 +0000 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iECKF-0007XF-9S for pgsql-hackers@postgresql.org; Sat, 28 Sep 2019 12:59:54 +0000 Received: by mail-wm1-x344.google.com with SMTP id f22so8115200wmc.2 for ; Sat, 28 Sep 2019 05:59:50 -0700 (PDT) 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=WeG3BfUFDzsn2s4Er1Zpr7+wk8LlRlFFe//g6OzvqUs=; b=deMn3tcROO2K6Il4NmbRHu7IBakIm6f11vYYMVrrx7g24qU6lJphQ01d01Yk4DIaiD +4HjjCbS6RNrr79VsIhNgF12DcouEZn5u3WwVGXL4VXtOwdeZdAu5AYRz4dGy2d12kzJ u4FY0xyIkENf3hNXZLFzqF+rNwoIL0hUJE2IuzzFn2Pqtnh2bFvyBdJJIAI+GM2kVKH6 4nAjCZp7kfghNHnQsAvC1E+E43mRyrneZB7VuL89L8H1WQ0Ayoqx/6PopZIo+Oa5YvyS HB+Q7Ietlddv4CN9VBtQ/jk3lX2zvhCT2E3a7f3LMkhNJtpKCpDNeFg+PXy87kFwWsiy YGhA== 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=WeG3BfUFDzsn2s4Er1Zpr7+wk8LlRlFFe//g6OzvqUs=; b=ZTqutmK7zy8z11zg2pIdlNSlO5c/iwYFGQ86FIRl0ygtJymq4o4n+X2jY65ukdYgtu EuRF/pQUVTYvYssm9H86nZjvfdzeJQq/bwodTbjUECcHafDeLJz9ePxXFioRbzJ7AlwY c4OA1ym+T6qzxflHT6GsqIqAs3K9DvS++SxEOgxdh6D1/pnXZqe+PJUMBOPWj5rtDBTc XyErvfGJZUS/NWeYizn7iZjCUSUk9toZ5yM9fQskLx6EwrNXF8cytWr/s6goCIIcp1c0 hYtRRrnOHwAi5a6PCiAROSkg1ECxUBH3NwuqFafeY/ZEpyRwVu625fpJrr4QxCKEyKCu Yp0w== X-Gm-Message-State: APjAAAW8V1iRXvSz2QapevsCEpJD44UYsVqRoLhtx5d70MkQQSolAMC5 4Cs4VCSyFJrAdt1u5Hg2SWMO4Q== X-Google-Smtp-Source: APXvYqzAiUPNdocZHolWwmUbJG+bhYHsxjTEUY+zbX2Fgx2R5FVvDfeBi4Yw5iPYAW5bhq2t7qen0w== X-Received: by 2002:a1c:984b:: with SMTP id a72mr10690579wme.149.1569675590126; Sat, 28 Sep 2019 05:59:50 -0700 (PDT) Received: from antos ([77.87.240.5]) by smtp.gmail.com with ESMTPSA id y186sm24176559wmb.41.2019.09.28.05.59.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Sep 2019 05:59:49 -0700 (PDT) From: Antonin Houska To: Alvaro Herrera cc: Thomas Munro , Robert Haas , "pgsql-hackers@postgresql.org" Subject: Re: Attempt to consolidate reading of XLOG page In-reply-to: <7753.1569658465@antos> References: <20190927191736.GA13447@alvherre.pgsql> <7753.1569658465@antos> Comments: In-reply-to Antonin Houska message dated "Sat, 28 Sep 2019 10:14:25 +0200." 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: <9235.1569675635.1@antos> Date: Sat, 28 Sep 2019 15:00:35 +0200 Message-ID: <9236.1569675635@antos> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Antonin Houska wrote: > Alvaro Herrera wrote: > > > BTW that tli_p business to the openSegment callback is horribly > > inconsistent. Some callers accept a NULL tli_p, others will outright > > crash, even though the API docs say that the callback must determine the > > timeline. This is made more complicated by us having the TLI in "seg" > > also. Unless I misread, the problem is again that the walsender code is > > doing nasty stuff with globals (endSegNo). As a very minor stylistic > > point, we prefer to have out params at the end of the signature. > > XLogRead() tests for NULL so it should not crash but I don't insist on doing > it this way. XLogRead() actually does not have to care whether the "open > segment callback" determines the TLI or not, so it (XLogRead) can always > receive a valid pointer to seg.ws_tli. This is actually wrong - seg.ws_tli is not always the correct value to pass. If seg.ws_tli refers to the segment from which data was read last time, then XLogRead() still needs a separate argument to specify from which TLI the current call should read. If these two differ, new file needs to be opened. The problem of walsender.c is that its implementation of XLogRead() does not care about the TLI of the previous read. If the behavior of the new, generic implementation should be exactly the same, we need to tell XLogRead() that in some cases it also should not compare the current TLI to the previous one. That's why I tried to use the NULL pointer, or the InvalidTimeLineID earlier. Another approach is to add a boolean argument "check_tli", but that still forces caller to pass some (random) value of the tli. The concept of InvalidTimeLineID seems to me less disturbing than this. -- Antonin Houska Web: https://www.cybertec-postgresql.com