Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5ze9-0000nx-ME for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Sep 2018 20:45:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g5ze7-0006td-Ll for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Sep 2018 20:45:55 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5ze7-0006tW-BS for pgsql-hackers@lists.postgresql.org; Fri, 28 Sep 2018 20:45:55 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5ze5-0008Bv-27 for pgsql-hackers@postgresql.org; Fri, 28 Sep 2018 20:45:54 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w8SKjnEm001903; Fri, 28 Sep 2018 16:45:49 -0400 From: Tom Lane To: Andres Freund cc: Peter Eisentraut , Sergei Kornilov , PostgreSQL mailing lists Subject: Re: Continue work on changes to recovery.conf API In-reply-to: <20180928204042.boqbpggazp656ie7@alap3.anarazel.de> References: <607741529606767@web3g.yandex.ru> <594281529606887@web2j.yandex.ru> <3595211530445522@web17o.yandex.ru> <64b6e400-74fa-3b30-5bcf-4d6a1facbf27@2ndquadrant.com> <1312381535557435@iva1-a2ffb02749cf.qloud-c.yandex.net> <22e02b05-cd56-6a6b-962d-6d35995827a5@2ndquadrant.com> <1563.1538166995@sss.pgh.pa.us> <20180928204042.boqbpggazp656ie7@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Fri, 28 Sep 2018 13:40:42 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1901.1538167549.1@sss.pgh.pa.us> Date: Fri, 28 Sep 2018 16:45:49 -0400 Message-ID: <1902.1538167549@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andres Freund writes: > On 2018-09-28 16:36:35 -0400, Tom Lane wrote: >> No, they MUST be independently verifiable. The interactions between >> the check_xxx functions in this patch are utterly unsafe. We've >> learned that lesson before. > I'm not sure those concerns apply quite the same way here - we can move > the interdependent verification to the the point where they're used > first rather than relying on guc.c infrastructure. And, if they're bad, what happens? Recovery fails? I don't think it's a great idea to lose out on whatever error checking the existing GUC infrastructure can provide, just so as to use a GUC design that's not very nice in the first place. regards, tom lane