| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_hosts: Add pg_hosts_file_rules() |
| Date: | 2026-07-12 20:47:02 |
| Message-ID: | 1EB12E6D-37A7-48CF-A27A-50FF0BDDB6BC@yesql.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 8 Jul 2026, at 18:03, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
> While working on the configuration file format proposal, I noticed
> that we are missing pg_hosts_file_rules, the pg_hosts version of
> pg_hba_file_rules.
>
> The attached patch adds this functionality, mirroring how the hba
> version is implemented.
Thanks for your patch!
I think it's a good idea to add this. One thing I have been puzzling over is
what to do with LibreSSL builds which don't support ssl_sni. One could argue
that parsing the file doesn't require ssl_sni actually function, so the view
could still work, but on the other hand it might be confusing to users to learn
that their file doesn't generate any errors yet ssl_sni doesn't work. I think
I prefer if the view is blank and the file isn't parsed in clusters which
doesn't support ssl_sni. What are your thoughts on that?
> One detail I am definitely unsure about is the first rule_number
> column, since pg_hosts is explicitly unordered, we might not want to
> add it. I included it in 0001 for parity with hba_file_rules and
> completeness.
Consistency is good, but since the number in this view doesn't convey the same
meaning as the corresponding column for hba parsing I think we should omit it.
It adds no value on top of consistency and can at worst be misleading.
A few small comments on the patch:
+ The view <structname>pg_hosts_file_rules</structname> provides a summary of
+ the contents of the hosts configuration file, which maps incoming TLS
+ server name indication (SNI) host names to SSL certificate configuration.
I think this has too many moving parts to not have links to the corresponding
doc sections in order to help the reader. I propose something like the below
instead:
The view <structname>pg_hosts_file_rules</structname> provides a
summary of the contents of the <link linkend="hosts_file">hosts
configuration file</link>, which maps incoming TLS connections with
<xref="sslsni"/> set to SSL certificate configurations.
+# A malformed entry shows up as an error row, not a thrown error.
+$node->append_conf('pg_hosts.conf', "this line has too many fields a b c d e f");
+$node->reload;
+my $errs = $node->safe_psql('postgres',
+ "SELECT count(*) FROM pg_hosts_file_rules() WHERE error IS NOT NULL");
+ok($errs >= 1, "pg_hosts_file_rules: malformed conf entry becomes an error row");
This test doesn't need the ->reload command here does it, since the view parses
whats on the filesystem and not what's running. Also, since we know the view
shall have a single row with an error we should test for == 1 instead of >= 1.
Similarily, the previous test doesn't need to restart the cluster?
--
Daniel Gustafsson
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2026-07-12 20:59:37 | Re: allow spread checkpoints when changing checksums online |
| Previous Message | Bharath Rupireddy | 2026-07-12 20:26:00 | Re: Introduce XID age based replication slot invalidation |