Re: [PATCH] Find additional connection service files inpg_service.conf.d directory - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: [PATCH] Find additional connection service files inpg_service.conf.d directory
Date
Msg-id 48a7c7a2-cb6f-faab-e59e-359ac7750dfb@iki.fi
Whole thread Raw
In response to Re: [PATCH] Find additional connection service files inpg_service.conf.d directory  (Curt Tilmes <curt@tilmes.org>)
Responses Re: [PATCH] Find additional connection service files inpg_service.conf.d directory  (Curt Tilmes <curt@tilmes.org>)
List pgsql-hackers
Handy feature!

On 01/03/18 20:40, Curt Tilmes wrote:
> On Thu, Mar 1, 2018 at 1:13 PM, Andres Freund <andres@anarazel.de> wrote:
>> And within the directory which service file wins will be decided by
>> filesystem internals. That makes me a bit uncomfortable, this very well
>> might not be stable.  I think it might not be terrible idea to sort the
>> directory and process alphabetically?
> 
> My preference would be not to do this.  I added a note to the doc about
> this.

I also think we should process the files in alphabetical order. That's 
how most software with conf.d directories work.

Imagine that you place "good.conf" and "bad.conf" in the config dir, and 
they both accidentally contain a service called "foobar". Everything 
seems to work fine, because the filesystem happens to return good.conf 
first. Then you take a backup of your system with "tar", and restore it 
on another system. On that system, "bad.conf" happens to be returned 
first, and it doesn't work. That's nightmare to debug.

Should we also search ~/.pg_service.conf.d ? And a PGSERVICEDIR env 
variable, to mirror PGSERVICEFILE. I don't think many people would use 
those, but I feel like it would be good to have consistency, so that 
wherever we search for "pg_service.conf" file, we also search for 
"pg_service.conf.d" directory.

- Heikki


pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: print_path is missing GatherMerge and CustomScan support
Next
From: Mai Peng
Date:
Subject: Re: Segfault logical replication PG 10.4