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 1i5rqb-00030L-HF for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Sep 2019 13:30:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1i5rqa-0004Nr-13 for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Sep 2019 13:30:48 +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 1i5rqZ-0004HJ-HK for pgsql-hackers@lists.postgresql.org; Thu, 05 Sep 2019 13:30:47 +0000 Received: from mail-qt1-x844.google.com ([2607:f8b0:4864:20::844]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i5rqR-0000uY-RY for pgsql-hackers@postgresql.org; Thu, 05 Sep 2019 13:30:46 +0000 Received: by mail-qt1-x844.google.com with SMTP id r5so2817572qtd.0 for ; Thu, 05 Sep 2019 06:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=vo16dHQcD73A6rHvA/A0jopG9CInRRAW+D9/jxBHRps=; b=wW71tGPQLiFD7QdI83hO9lMgqS9Na+9/z9TbJyee7a6Hxm2F0AsI2Hs8mr3ToyNPMR LQV9A1QNFE8wC2mUXw8oduyqK6JFnuZ07xRm91sG6mQVm/Zd9s/bFNg6wjZLJegOKqku wN06VW3hIGk05N+EZt9WCpGEG0AadKzPgwrAhln1uE4HY1liZh6IeRh8xiTnpRZUfHh2 9zkuV5/OPCogpFmGXZ2UbBztXCwrbGhEpBY8q0ziyYVv0FoG7IlXPvWYTO/3zKAexj2H J46J3R90U3FI/7afV9+UUQ4+Yz00/K40XZLRgQ0BYXvegz6myFeOyHo+19OqkNYs+46w 4VeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=vo16dHQcD73A6rHvA/A0jopG9CInRRAW+D9/jxBHRps=; b=sYBSMYsAMzDkMAd9frugifHi9NxvppotqKqoTqHoefrzbjEA9nY0CaBYGrJwhWnwSF MiXGr3RCADzaWR4xIBPmWOEUk+7PCHtpSh7i7ibihGjgsRU7gRRG5v0VUPXK5geNWBL1 joo79S5ZgS4elhfzxNahQEqDWo/nwWBZ57sMFOWJixpaks94LG9XS6hAQrl1VYGtcWgT FUVcbnwj192ZhMbX3BC6jyalZasYc7EHil/ZWMiFU6sGWI+HH6zsBuGHYU77EWCnM8Fb JDyP6TyeoIJ8pzOtsmnRQ8T8iiAVKhvHi6dWvC9H/whcE1TOvfLYyWO5eFWMQQYiByUt Qk1A== X-Gm-Message-State: APjAAAWTemwks6VKpWn+q4z3G9FtCMudo28bVEjb1bUX7Z8POalt5N2j M/PmlW9YGkIvQ2OQEOXHvUADLXjaZ6g= X-Google-Smtp-Source: APXvYqxPp0A68fauAKM3gYEpYYp1SInGUQrR2eLT3TntiDkjzjwAX8BYOeBLsLAMDCUUncAYDOfXoQ== X-Received: by 2002:a0c:ac4b:: with SMTP id m11mr1669255qvb.103.1567689798526; Thu, 05 Sep 2019 06:23:18 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id e7sm1119998qtb.94.2019.09.05.06.23.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Sep 2019 06:23:15 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 41E14123D5A; Thu, 5 Sep 2019 09:23:11 -0400 (-04) Date: Thu, 5 Sep 2019 09:23:11 -0400 From: Alvaro Herrera To: Paul Guo Cc: Michael Paquier , Thomas Munro , pgsql-hackers , Jimmy Yih , Ashwin Agrawal Subject: Re: Two pg_rewind patches (auto generate recovery conf and ensure clean shutdown) Message-ID: <20190905132311.GA22775@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Thank for rebasing. I didn't like 0001 very much. * It seems now would be the time to stop pretending we're using a file called recovery.conf; I know we still support older server versions that use that file, but it sounds like we should take the opportunity to rename the function to be less misleading once those versions vanish out of existance. * disconnect_and_exit seems a bit out of place compared to the other parts of this new module. I think you only put it there so that the 'conn' can be a global, and that you can stop passing 'conn' as a variable to GenerateRecoveryConf. It seems more modular to me to keep it as a separate variable in each program and have it passed down to the routine that writes the file. * From modularity also seems better to me to avoid a global variable 'recoveryconfcontents' and instead return the string from GenerateRecoveryConf to pass as a param to WriteRecoveryConf. (In fact, I wonder why the current structure is like it is, namely to have ReceiveAndUnpackTarFile write the file; why wouldn't be its caller be responsible for writing it?) I wonder about putting this new file in src/fe_utils instead of keeping it in pg_basebackup and symlinking to pg_rewind. Maybe if we make it a true module (recovery_config_gen.c) it makes more sense there. 0002 seems okay as far as it goes. 0003: I still don't understand why we need a command-line option to do this. Why should it not be the default behavior? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services