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 1hdSNR-00047B-Ng for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Jun 2019 04:39:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hdSNQ-00067v-9s for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Jun 2019 04:39:16 +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 1hdSNP-00067o-Sd for pgsql-hackers@lists.postgresql.org; Wed, 19 Jun 2019 04:39:16 +0000 Received: from mail-pf1-x441.google.com ([2607:f8b0:4864:20::441]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hdSNM-00080v-FZ for pgsql-hackers@postgresql.org; Wed, 19 Jun 2019 04:39:15 +0000 Received: by mail-pf1-x441.google.com with SMTP id p184so8950433pfp.7 for ; Tue, 18 Jun 2019 21:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=nEZYuHrmFBoy2OOM4nsNRwlt3vKDSpRxT2GAEBAv79o=; b=BLwSe0xHw6JUU4IQ1JKo3+EI5AOgOdzgqZSpvcPdkOVSVdY1+tGvEvbOfeBa4M5mCD pQ0OaUiRuQDexJ221vGyQ37K0PmLFgE56MHwjcKeXW1c/5nth0hmbdQ8BG+1ZNADBEV9 vWQP8BnubelN0VLbhgjAMi52CllWVoHloqdXH7CPdlHlLzXBtI8Q86orP+P0gIAodFtU 6pOC1TBU6ReiohqbhglS16OttRIGoWytwamZPBLGwP6EcwHQ2SdbSSDWiyoWJdxbqnCc WONcVqmiaRaB5tL1pPfdLSGQMnYz5dOIQBK07QPpkgsp9v9oAIYVZ0UGxyYQ85k/vN0+ KwFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nEZYuHrmFBoy2OOM4nsNRwlt3vKDSpRxT2GAEBAv79o=; b=XxzLQvFNSxAaBqA2bdI9G4V8mdRmg3fUDh9c+l1rMuokYT0u1VLIYjN57idkdyTIfk +cN/OiMGA6E9cDzJqIVlrdjNIIW6PcZweBQ3pmv/tqDhqGKI3J49uC2/5fPfjykHx5no me/GpCOSOueoylZEfRYNjfHTGNf6HaCrIM+60U/hnwQOrdc5FuipZfd9rZg9kfGMgGwR 4IFnNTY2QIlUXVCqmxqsmd+o/A5XGqNgW2su8lwuFaYYGRvIncRdkugDd1okwFEVrOna h5ogqvNqN+W8R3NBxX5TL17PDdHrazyWW0kNmywCDT3ILYKCWEISZHGhFMl+GX4Cli+K 5eTw== X-Gm-Message-State: APjAAAUAnYnSSPFY1k5qmVXyCmmiFEeKWv0d5MvBvo0M+fj5f2ZPFKMm H3pj4DbxuXkI2vn4Porz/zaYk7iqNezTIRN4Zqr9P0ULYOsmNNfIjMeDgs7homoc++5APfAjleg kfB1EemVcdJRhVFzHWIlVgX4xFlBzlX78iMvOhd8AN+683iqJvpcAWGck13F8Kn14f+Vs4TPPcZ V7jdNrpgH7BAKE X-Google-Smtp-Source: APXvYqzkRGqdm1wnwRXqF2RA7PlTRLv3YvmVi9J1WVWCoBNwUWXxHD9nWxzeeHXPUn8F/VWRkinGVg== X-Received: by 2002:aa7:8812:: with SMTP id c18mr115199pfo.60.1560919149702; Tue, 18 Jun 2019 21:39:09 -0700 (PDT) Received: from osaka.octopusnet (p14091-ipngn9701marunouchi.tokyo.ocn.ne.jp. [153.219.173.91]) by smtp.gmail.com with ESMTPSA id 3sm16648380pfp.114.2019.06.18.21.39.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jun 2019 21:39:08 -0700 (PDT) Subject: Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions To: Amit Kapila Cc: Stephen Frost , "pgsql-hackers@postgresql.org" References: <20190614160835.GF2480@tamriel.snowman.net> <20190616171610.GO2480@tamriel.snowman.net> <27dc9f8d-8d8f-9dd1-0494-5d8bd2f49a45@2ndquadrant.com> From: Ian Barwick Message-ID: <75425921-0829-e84a-392e-168081dac6e7@2ndquadrant.com> Date: Wed, 19 Jun 2019 13:39:05 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 6/19/19 12:46 PM, Amit Kapila wrote: > On Mon, Jun 17, 2019 at 8:20 PM Ian Barwick wrote: >> On 6/15/19 1:08 AM, Stephen Frost wrote: >> > * Amit Kapila (amit.kapila16@gmail.com) wrote: >> >> Right. I think if possible, it should use existing infrastructure to >> >> write to postgresql.auto.conf rather than inventing a new way to >> >> change it. Apart from this issue, if we support multiple ways to edit >> >> postgresql.auto.conf, we might end up with more problems like this in >> >> the future where one system is not aware of the way file being edited >> >> by another system. >> > >> > I agere that there should have been some effort put into making the way >> > ALTER SYSTEM is modified be consistent between the backend and utilities >> > like pg_basebackup (which would also help third party tools understand >> > how a non-backend application should be modifying the file). >> >> Did you mean to say "the way postgresql.auto.conf is modified"? >> > > Yes, that is what we are discussing here. I think what we can do here > is to extract the functionality to set the parameter in .auto.conf > from AlterSystemSetConfigFile and expose it via a function that takes > (option_name, value) as a parameter. Yup, I was just considering what's involved there, will reply to another mail in the thread on that. > Then we can expose it via some > SQL function like set_auto_config (similar to what we have now for > set_config/set_config_by_name). I think if we have something like > that then pg_basebackup or any other utility can use it in a > consistent way. Umm, but the point is here, the server will *not* be running at this point, so calling an SQL function is out of the question. And if the server is running, then you just execute "ALTER SYSTEM". Regards Ian Barwick -- Ian Barwick https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services