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 1hYBq2-0007LI-89 for pgsql-hackers@arkaria.postgresql.org; Tue, 04 Jun 2019 15:59:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hYBq1-0002jF-4i for pgsql-hackers@arkaria.postgresql.org; Tue, 04 Jun 2019 15:59:01 +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 1hYBq0-0002gv-Rc for pgsql-hackers@lists.postgresql.org; Tue, 04 Jun 2019 15:59:00 +0000 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hYBpy-00059L-Lk for pgsql-hackers@postgresql.org; Tue, 04 Jun 2019 15:59:00 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 1A9F4498; Tue, 4 Jun 2019 11:58:56 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 04 Jun 2019 11:58:56 -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=lSpPvPKZ81eU/q70XcqBxGsgYg+ UknCX/+DIBdGGkAI=; b=4qOu+Z2DuWEWVP7Iu7xWuCppIpDgDnq6nBI99d4nd1e xwxHBDvsT128bG93ip/yQVig4VPCT3rWzw6pB8mXk7dlIzOg53Wa5SLpPVeM9pXR iZMF4SWB0/DamHP2Za9PgfIMqxWsGI0poA7q/mHTwtxFgP87EcuyArcAIMY3e9Hm r5NQpfDW3JXQLtlG8A8EC6Q9K/vftqvxgNcZTXBIjBd1IA1T+MTSu6HP/KYDWpjl neU6wMgpfQkRg/xtMUVlehppNkbFLA/5kcE0uIWYjigpSncVwYcMNs82AgoO+SWU U4/CmelEsPjrOBQDwmrHS7ounCctv9lqBdp+b66e9NA== 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=lSpPvP KZ81eU/q70XcqBxGsgYg+UknCX/+DIBdGGkAI=; b=WVm29GbRzmNrae+Gmfo+W9 vLTgRdff50agpKNAVy5Q00akbqmi1Y+UHd/OYNlxOm/2MolyYznC52MxzsUkZG3r cyTdeuGzz8vpJvw3UEJKhkVXugGkH4F2InEFlr+CX58qs/ao1wsXh60YtxUd9QPS gTlsRmGyhPiY5+Oak8zrgMI9L96op3C8UaINqZc+gVIf/CoK3OHcekaWSIIkI9ze PKUwdqn/iN+1Jmge15I9pf4nbYUyuysaQTnW6WD17skrlMHIotObnU74kPm8uvgp pcmmBtlUjSxmzUUAxuUVtqp1NhOeA1yyhgrHJkmZQZaN1B3gHVVyalkXzCxaW3vg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudefledgleeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeetnhgurhgv shcuhfhrvghunhguuceorghnughrvghssegrnhgrrhgriigvlhdruggvqeenucfkphepie ejrdduiedtrddvudekrddvfeejnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrnhgurhgv shesrghnrghrrgiivghlrdguvgenucevlhhushhtvghrufhiiigvpedv X-ME-Proxy: Received: from intern.anarazel.de (c-67-160-218-237.hsd1.ca.comcast.net [67.160.218.237]) by mail.messagingengine.com (Postfix) with ESMTPA id F0DDF38008F; Tue, 4 Jun 2019 11:58:54 -0400 (EDT) Date: Tue, 4 Jun 2019 15:58:53 +0000 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: <20190604155853.6oiirwpbvcpubr5s@alap3.anarazel.de> References: <20190523174821.s3kgumgmo35opavg@alap3.anarazel.de> <20190527135602.dw6cp5vttbdb76i7@alap3.anarazel.de> <20190530141723.ox5y4wda6alvo4uj@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-06-04 15:51:01 +0530, Amit Khandekar wrote: > After giving more thought on this, I think it might make sense to > arrange for the xl_running_xact record to be sent from master to the > standby, when a logical slot is to be created on standby. How about > standby sending a new message type to the master, requesting for > xl_running_xact record ? Then on master, ProcessStandbyMessage() will > process this new message type and call LogStandbySnapshot(). I think that should be a secondary feature. You don't necessarily know the upstream master, as the setup could be cascading one. I think for now just having to wait, perhaps with a comment to manually start a checkpoint, ought to suffice? Greetings, Andres Freund