From: Michael Paquier <michael@paquier.xyz>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Cc: bruce@momjian.us
Cc: tgl@sss.pgh.pa.us
Subject: Re: GUC flags
Date: Sun, 6 Feb 2022 14:09:45 +0900
Message-ID: <Yf9YGSwPiMu0c7fP@paquier.xyz> (raw)
In-Reply-To: <20220131225645.GZ23027@telsasoft.com>
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>
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
Attachments:
[application/pgp-signature] signature.asc (832B, ../Yf9YGSwPiMu0c7fP@paquier.xyz/2-signature.asc)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: michael@paquier.xyz, pryzby@telsasoft.com, peter.eisentraut@enterprisedb.com, horikyota.ntt@gmail.com, pgsql-hackers@lists.postgresql.org, bruce@momjian.us, tgl@sss.pgh.pa.us
Subject: Re: GUC flags
In-Reply-To: <Yf9YGSwPiMu0c7fP@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox