Date: Sun, 6 Feb 2022 14:09:45 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	pgsql-hackers@lists.postgresql.org, bruce@momjian.us,
	tgl@sss.pgh.pa.us
Subject: Re: GUC flags
Message-ID: <Yf9YGSwPiMu0c7fP@paquier.xyz>
References: <d363c358-2c67-92bc-660f-ff82636c155f@enterprisedb.com>
 <20220125180751.GH23027@telsasoft.com>
 <YfCb03sRzkgNVwbL@paquier.xyz>
 <20220126034426.GN23027@telsasoft.com>
 <YfDqSVZlzdzZO9x6@paquier.xyz>
 <20220128043621.GA23027@telsasoft.com>
 <YfTg/WHNLVVygy8v@paquier.xyz>
 <20220130001849.GR23027@telsasoft.com>
 <Yfdw9WWJ/BMl7QYd@paquier.xyz>
 <20220131225645.GZ23027@telsasoft.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="mgEvZ4VLfh7QrvPb"
Content-Disposition: inline
In-Reply-To: <20220131225645.GZ23027@telsasoft.com>
Archived-At: 
 <https://www.postgresql.org/message-id/Yf9YGSwPiMu0c7fP%40paquier.xyz>
Precedence: bulk


--mgEvZ4VLfh7QrvPb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Jan 31, 2022 at 04:56:45PM -0600, Justin Pryzby wrote:
> I'm not clear on what things are required/prohibited to allow/expect
> "installcheck" to pass.  It's possible that postgresql.conf doesn't even exist
> in the data dir, right ?

There are no written instructions AFAIK, but I have as personal rule
to not break the tests in configurations where they worked
previously.

> It's okay with me if the config_file-reading stuff isn't re-implemented.

Actually, I am thinking that we should implement it before retiring
completely check_guc, but not in the fashion you are suggesting.  I
would be tempted to add something in the TAP tests as of
src/test/misc/, where we initialize an instance to get the information
about all the GUCs from SQL, and map that to the sample file located
at pg_config --sharedir.  I actually have in my patch set for
pg_upgrade's TAP a perl routine that could be used for this purpose,
as of the following in Cluster.pm:

+=item $node->config_data($option)
+
+Grab some data from pg_config, with $option being the command switch
+used.
+
+=cut
+
+sub config_data
+{
+   my ($self, $option) = @_;
+   local %ENV = $self->_get_env();
+
+   my ($stdout, $stderr);
+   my $result =
+     IPC::Run::run [ $self->installed_command('pg_config'), $option
],
+     '>', \$stdout, '2>', \$stderr
+     or die "could not execute pg_config";
+   chomp($stdout);
+   $stdout =~ s/\r$//;
+
+   return $stdout;
+}

What do you think?  (I was thinking about applying that separately
anyway, to lower the load of the pg_upgrade patch a bit.)
--
Michael

--mgEvZ4VLfh7QrvPb
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmH/WBkACgkQnvQgOdby
QH1i8Q//Xg7MntlsjVkCMNla1kvLzskKm3qJdl56JLUFNeLj+aXThsfpW5xvVgRf
c6UChQ8mn7cmvLMNy1xMwGhkHbOLfJhddnYHCzmXMY2eKfM3U9J35SBUefX/tGAz
PLWlWKn+ig++UOwPk04HfuxPTZNmJ4TON+JXAQVSwPZh8gcnksEQkhjouw2OwJ94
B5CJ5a/QSschAVZZUSo8qhc1fUdqWvvHx9z08C7KZI04xlr7lowDsDnMWo8WXyun
YiM0F4PvmFWZmYQ0wtuWGhgh6vmEMmnDnIKk1zm9C5dGeWmVuQ/FD/YOFHTQtg8u
38THb/6qoG3CpCn/JFtKtR7GfPzIrdCLCbFU+KTr8EMRR7J4VENayHbeIgUYWToj
5vsAcTo8skAXB8gM8Lwfxe/Xmlv5Pq8HOvNRIGt7PbQhGtNndvq5az4czfN7YVuP
ICiRV98sTS74dWzc76WgQ0fINvVQAomE7QdDNH3F4Y0I97A0eH8UD2XfV1xNdfet
jA1GsMZqNcYmZA8lsrX1qQB09l/6UJ3PYSAC7D//QCF4BwjenQ2msdWkZJgwDvPH
9chV5evYTM05IL8yCwkXfMGP2TBWKQTlAXGlVk2I+c2dEHZ5l/ogkxS/RrYKZHdb
1EJ2Yd5kl0UBcaGAqQrjqUD3MlT0e1bZ48ctR+ZzTR6C5R9vJu0=
=s3qu
-----END PGP SIGNATURE-----

--mgEvZ4VLfh7QrvPb--