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 1hTq7b-0007NP-4T for pgsql-hackers@arkaria.postgresql.org; Thu, 23 May 2019 15:59:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hTq7Z-0004dd-S3 for pgsql-hackers@arkaria.postgresql.org; Thu, 23 May 2019 15:59:09 +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 1hTq7Z-0004aY-HI for pgsql-hackers@lists.postgresql.org; Thu, 23 May 2019 15:59:09 +0000 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hTq7X-0005NV-9r for pgsql-hackers@postgresql.org; Thu, 23 May 2019 15:59:09 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 074396DB; Thu, 23 May 2019 11:59:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 23 May 2019 11:59:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=icCGUsp72hKZ4NyQcolvdEm7YJN 0OYh8h7v4BlGJxnM=; b=Nqv4DrbfRdJtrf76xLe36zxlz+HkaaOLisoOdWSh40L qeh7pRVTJGu3Ry0sZFf3t5lUufrr+UiWe5fq7qUzw5jHSTLSw8PvVRtMkcrYdzPm J7QQbtDDnugyvPiJSjivGiqFDLGjkhyAKXgqpJLwkVGhaTn5ddAYkE8JiXTIOv3T flwUDHnaclkzNFbnboZcgv632NKuxkt1NxzBnyaF0G97B7BnIZiyK0wXkhDaELXk 6ZqFD03sY012Zi9eySNELklYJfKElaBYLo156RKeFVxWymXYkkIIaX5+RA/1WLx8 24oEbW/qsqD6wiF3FZIxYPw99+7JP9T+UKQKai2mkZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=icCGUs p72hKZ4NyQcolvdEm7YJN0OYh8h7v4BlGJxnM=; b=a21JOq/2YyOre5qmKuRR1H Njr3uZ0YeUy/Sf4wFApXC1oThuULngmBmKmivFXUPKc1gc8a/QQrcZ6jdyAJlp2h k6DBbsof/CZlf18Wj9dicJBFmueaOpb6KzG2ZL7wxcBIcsNGLroiCRSyNCmjlgjG PszqjfQ7E06RdVBTZlYY0mXIVEHtQqEy19vNUOh7+Wm3Zs36R0kBML0pxpjCM/FQ DT/7SeJXlddU5Hfl9m/ytePvYL1dKL1RhSvo0nVBlTx0UMS2a6OUDzrgK7bf6V6w Xgjpu4tj1uFEyqg0DvA14Nen31nXBk/4AtHMtjXXxTIVSKtTEimbMgZ8wpN1TRgw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddugedgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeetnhgurhgv shcuhfhrvghunhguuceorghnughrvghssegrnhgrrhgriigvlhdruggvqeenucfkpheple ekrddvuddtrddugedtrddujedunecurfgrrhgrmhepmhgrihhlfhhrohhmpegrnhgurhgv shesrghnrghrrgiivghlrdguvgenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from intern.anarazel.de (c-98-210-140-171.hsd1.ca.comcast.net [98.210.140.171]) by mail.messagingengine.com (Postfix) with ESMTPA id CB4FE8005C; Thu, 23 May 2019 11:59:02 -0400 (EDT) Date: Thu, 23 May 2019 08:59:01 -0700 From: Andres Freund To: Amit Khandekar Cc: tushar , Petr Jelinek , Robert Haas , Craig Ringer , Petr Jelinek , pgsql-hackers Subject: Re: Minimal logical decoding on standbys Message-ID: <20190523155901.acm4umrl6adrcwt4@alap3.anarazel.de> References: <20190304172739.hdkwmtngwx5444un@alap3.anarazel.de> <9fce660d-47fc-4294-3084-3769e543da8a@enterprisedb.com> <53656d0c-1868-86e8-54a6-216ce74b353a@enterprisedb.com> <8af22fc0-d08c-f3fa-e7ec-dfb153b3d7b4@enterprisedb.com> <20190410160925.c4sat4ex67blinhy@alap3.anarazel.de> <20190412192747.m73h2qnddrpzefij@alap3.anarazel.de> <20190521161937.tpepqkiatw6kv35v@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 2019-05-23 17:39:21 +0530, Amit Khandekar wrote: > On Tue, 21 May 2019 at 21:49, Andres Freund wrote: > Yeah, I agree we should add such checks to minimize the possibility of > reading logical records from a master that has insufficient wal_level. > So to summarize : > a. CheckLogicalDecodingRequirements() : Add Controlfile wal_level checks > b. Call this function call in CreateInitDecodingContext() as well. > c. While decoding XLOG_PARAMETER_CHANGE record, emit recovery conflict > error if there is an existing logical slot. > > This made me think more of the race conditions. For instance, in > pg_create_logical_replication_slot(), just after > CheckLogicalDecodingRequirements and before actually creating the > slot, suppose concurrently Controlfile->wal_level is changed from > logical to replica. So suppose a new slot does get created. Later the > slot is read, so in pg_logical_slot_get_changes_guts(), > CheckLogicalDecodingRequirements() is called where it checks > ControlFile->wal_level value. But just before it does that, > ControlFile->wal_level concurrently changes back to logical, because > of replay of another param-change record. So this logical reader will > think that the wal_level is sufficient, and will proceed to read the > records, but those records are *before* the wal_level change, so these > records don't have logical data. I don't think that's an actual problem, because there's no decoding before the slot exists and CreateInitDecodingContext() has determined the start LSN. And by that point the slot exists, slo XLOG_PARAMETER_CHANGE replay can error out. Greetings, Andres Freund