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 1mFmfL-0006hJ-AR for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Aug 2021 00:09:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mFmfJ-00055b-4Y for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Aug 2021 00:09:13 +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 1mFmfI-0004zK-6Z for pgsql-hackers@lists.postgresql.org; Tue, 17 Aug 2021 00:09:12 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mFmfE-0006ud-77 for pgsql-hackers@postgresql.org; Tue, 17 Aug 2021 00:09:11 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id A59CE5C01EB; Mon, 16 Aug 2021 20:09:06 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 16 Aug 2021 20:09:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=gQPTZCNd0oNl2ast17eB6sVw7JYBwo9dSbLBuZe2lqg=; b=TXvoIl+9 6MdU/bAzDj0ThpjGPlnGXOpCTmXU8HhScGDWlsJPnhSdJ5xJXGsso49u4b00wwbw xO+h7bdsHMia+sMw0Isi8c4sUCjyUu4ge5S3yH22QfopwVnZQ1gAvTaNF41jkXtI JEDa3RltdchCifIGALwrTlV+fr/TkUzbyQ/ivc6qsDuBb4C1EwWWVJOos2VHH1HG /HEi0p3xrfPbs6nbVmLL830V0ru+ZJwFA6pHKZ94ikL7rYMiI5g1fqSW53PwKx2R YYzJQ8Oo4BSmfQkZomRn+cTRhtd9ThS1SQHqwcbI7DZXML1pU1NkLxw4oWOu3pDh GYZdfjmx/G7tBw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrledvgdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkgggtugfgjgesthekredttddtjeenucfhrhhomhepfdgrlhhvhhgv rhhrvgesrghlvhhhrdhnohdqihhprdhorhhgfdcuoegrlhhvhhgvrhhrvgesrghlvhhhrd hnohdqihhprdhorhhgqeenucggtffrrghtthgvrhhnpefhudeftdfhleevgeejtdffudel keeiudfgtdfgtddtveetjeelteeghfeuiefgteenucffohhmrghinhepvghnthgvrhhprh hishgvuggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 16 Aug 2021 20:09:03 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 9608D2A099B; Mon, 16 Aug 2021 20:09:00 -0400 (-04) Date: Mon, 16 Aug 2021 20:09:00 -0400 From: "alvherre@alvh.no-ip.org" To: "Bossart, Nathan" Cc: Kyotaro Horiguchi , "x4mmm@yandex-team.ru" , "a.lubennikova@postgrespro.ru" , "hlinnaka@iki.fi" , "matsumura.ryo@fujitsu.com" , "masao.fujii@gmail.com" , "pgsql-hackers@postgresql.org" Subject: Re: archive status ".ready" files may be created too early Message-ID: <202108170009.urejfpnljykf@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <867B852E-E892-4DD7-8E29-CE74FDBBA234@amazon.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk So why do we call this structure "record boundary map", when the boundaries it refers to are segment boundaries? I think we should call it "segment boundary map" instead ... and also I think we should use that name in the lock that protects it, so instead of ArchNotifyLock, it could be SegmentBoundaryLock or perhaps WalSegmentBoundaryLock. The reason for the latter is that I suspect the segment boundary map will also have a use to fix the streaming replication issue I mentioned earlier in the thread. This also makes me think that we'll want the wal record *start* address to be in the hash table too, not just its *end* address. So we'll use the start-1 as position to send, rather than the end-of-segment when GetFlushRecPtr() returns that. As for 0xFFFFFFFFFFFFFFFF, I think it would be cleaner to do a #define MaxXLogSegNo with that value in the line immediately after typedef XLogSegNo, rather than use the numerical value directly in the assignment. Typo in comment atop RemoveRecordBoundariesUpTo: it reads "up to an", should read "up to and". I think the API of GetLatestRecordBoundarySegment would be better by returning the boolean and having the segment as out argument. Then you could do the caller more cleanly, if (GetLatestRecordBoundarySegment(last_notified, flushed, &latest_boundary_segment)) { SetLastNotified( ... ); RemoveRecordBoundaries( ... ); LWLockRelease( ... ); for (..) XLogArchiveNotifySeg(...); PgArchWakeup(); } else LWLockRelease(...); -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ "La virtud es el justo medio entre dos defectos" (Aristóteles)