From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, bruce(at)momjian(dot)us, tgl(at)sss(dot)pgh(dot)pa(dot)us |
Subject: | Re: GUC flags |
Date: | 2022-02-06 05:09:45 |
Message-ID: | Yf9YGSwPiMu0c7fP@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2022-02-06 06:03:44 | Re: pg_upgrade should truncate/remove its logs before running |
Previous Message | Michael Paquier | 2022-02-06 04:36:07 | Re: pg_upgrade should truncate/remove its logs before running |