Обсуждение: Small doc patch about pg_service.conf
Folks, There was a slash missing, which I've added. Where is the default directory on Windows, or is there one? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Вложения
On Wed, Dec 31, 2014 at 3:24 PM, David Fetter <david@fetter.org> wrote:
Folks,
There was a slash missing, which I've added. Where is the default
directory on Windows, or is there one?
Applied, thanks.
And - from a quick check, it looks like it's actually using "/etc" on Windows as well. Which is somewhat weird, but in line with the documentation.
On Sat, Jan 03, 2015 at 01:22:02PM +0100, Magnus Hagander wrote: > On Wed, Dec 31, 2014 at 3:24 PM, David Fetter <david@fetter.org> wrote: > > > Folks, > > > > There was a slash missing, which I've added. Where is the default > > directory on Windows, or is there one? > > > > Applied, thanks. Thank you. > And - from a quick check, it looks like it's actually using "/etc" > on Windows as well. Which is somewhat weird, but in line with the > documentation. That is a little weird. Where should it be? Is it a case of now that it's one known place, we should exercise restraint when tempted to move it? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On Sat, Jan 03, 2015 at 01:22:02PM +0100, Magnus Hagander wrote: > On Wed, Dec 31, 2014 at 3:24 PM, David Fetter <david@fetter.org> wrote: > > There was a slash missing, which I've added. Where is the default > > directory on Windows, or is there one? > > > > Applied, thanks. The old and the new documentation are both wrong. The directory libpq consults is `pg_config --sysconfdir`, which is packager-selected but rarely matches /etc itself. parseServiceInfo() has the code in question.
On Sat, Jan 03, 2015 at 02:36:50PM -0500, Noah Misch wrote: > On Sat, Jan 03, 2015 at 01:22:02PM +0100, Magnus Hagander wrote: > > On Wed, Dec 31, 2014 at 3:24 PM, David Fetter <david@fetter.org> wrote: > > > There was a slash missing, which I've added. Where is the default > > > directory on Windows, or is there one? > > > > Applied, thanks. > > The old and the new documentation are both wrong. The directory libpq > consults is `pg_config --sysconfdir`, which is packager-selected but rarely > matches /etc itself. parseServiceInfo() has the code in question. On my Fedora system, $(pg_config --sysconfdir) is /etc. What should we put in the documentation? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter <david@fetter.org> writes:
> On Sat, Jan 03, 2015 at 02:36:50PM -0500, Noah Misch wrote:
>> The old and the new documentation are both wrong. The directory libpq
>> consults is `pg_config --sysconfdir`, which is packager-selected but rarely
>> matches /etc itself. parseServiceInfo() has the code in question.
> On my Fedora system, $(pg_config --sysconfdir) is /etc. What should
> we put in the documentation?
On an install-from-source, it's $installroot/etc. So the new
documentation is very definitely more wrong than the old, which
at least was vague about which etc directory it meant.
We could do worse than to say it's in the directory printed by
"pg_config --sysconfdir".
regards, tom lane
On Sat, Jan 03, 2015 at 03:03:45PM -0500, Tom Lane wrote: > David Fetter <david@fetter.org> writes: > > On Sat, Jan 03, 2015 at 02:36:50PM -0500, Noah Misch wrote: > >> The old and the new documentation are both wrong. The directory libpq > >> consults is `pg_config --sysconfdir`, which is packager-selected but rarely > >> matches /etc itself. parseServiceInfo() has the code in question. > > > On my Fedora system, $(pg_config --sysconfdir) is /etc. What should > > we put in the documentation? > > On an install-from-source, it's $installroot/etc. So the new > documentation is very definitely more wrong than the old, which > at least was vague about which etc directory it meant. > > We could do worse than to say it's in the directory printed by > "pg_config --sysconfdir". Something like the attached? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Вложения
On Sat, Jan 3, 2015 at 9:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
David Fetter <david@fetter.org> writes:
> On Sat, Jan 03, 2015 at 02:36:50PM -0500, Noah Misch wrote:
>> The old and the new documentation are both wrong. The directory libpq
>> consults is `pg_config --sysconfdir`, which is packager-selected but rarely
>> matches /etc itself. parseServiceInfo() has the code in question.
> On my Fedora system, $(pg_config --sysconfdir) is /etc. What should
> we put in the documentation?
On an install-from-source, it's $installroot/etc. So the new
documentation is very definitely more wrong than the old, which
at least was vague about which etc directory it meant.
Well, it's more correct for the vast majority of installations. And more wrong for others. I'd still say that it's a net improvement.
We could do worse than to say it's in the directory printed by
"pg_config --sysconfdir".
Yeah. But let's make sure we include "usually /etc" or something like that.
On 01/03/2015 04:41 PM, Magnus Hagander wrote: > > > We could do worse than to say it's in the directory printed by > "pg_config --sysconfdir". > > > Yeah. But let's make sure we include "usually /etc" or something like > that. > > But it's not usually /etc. Certainly it's not in the PGDG RPM builds unless they have changed recently. cheers andrew
On Sat, Jan 3, 2015 at 10:52 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
On 01/03/2015 04:41 PM, Magnus Hagander wrote:
We could do worse than to say it's in the directory printed by
"pg_config --sysconfdir".
Yeah. But let's make sure we include "usually /etc" or something like that.
But it's not usually /etc. Certainly it's not in the PGDG RPM builds unless they have changed recently.
I thought it was, based on Davids post from earlier. I know Debian moves them to /etc/postgresql-common - but they move a lot of the things around. I didn't realize the RPMs did something similar. If that's the case then it's definitely wrong to say that. I guess I haven't been using the system wide one on RedHat.
So yeah, in that case, then it's clearly wrong. But the current docs saying it's in etc/pg_service.conf is also wrong for almost everything in that case, so jus the pg_config mention seems right.
Magnus Hagander <magnus@hagander.net> writes:
> On Sat, Jan 3, 2015 at 10:52 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> On 01/03/2015 04:41 PM, Magnus Hagander wrote:
>>> Yeah. But let's make sure we include "usually /etc" or something like
>>> that.
>> But it's not usually /etc. Certainly it's not in the PGDG RPM builds
>> unless they have changed recently.
> I thought it was, based on Davids post from earlier. I know Debian moves
> them to /etc/postgresql-common - but they move a lot of the things around.
> I didn't realize the RPMs did something similar. If that's the case then
> it's definitely wrong to say that. I guess I haven't been using the system
> wide one on RedHat.
The reason the RH packages use /etc is that there's a distro-wide default
that configure gets invoked with --sysconfdir=/etc unless the packager
takes steps to override that. The RH postgresql packages *did* take steps
to override that, up till about Fedora 16/RHEL7 --- before then the
arrangement was --sysconfdir=/etc/sysconfig/pgsql. So David's comment
isn't even correct for the majority of Red Hat installations today.
Between that and your points about PGDG and Debian, it's clear that "/etc"
is wrong far more often than it's right.
I'd suggest wording along the lines of
... or it can be a system-wide file, which is named <filename>pg_service.conf</filename> and located in the directory
specifiedby the environment variable <envar>PGSYSCONFDIR</envar>. If that variable is not set, the system-wide file is
soughtin the directory displayed by <command>pg_config --sysconfig</command> (by default,
<filename><replaceable>installprefix</>/etc</filename>).
However, I don't know whether that advice also works for Windows;
can anyone check?
regards, tom lane
On Sat, Jan 03, 2015 at 02:36:50PM -0500, Noah Misch wrote: > The directory libpq consults is `pg_config --sysconfdir` I was wrong there. `pg_config --sysconfig` uses get_etc_path(), which adjusts to post-installation moves of the installation tree. parseServiceInfo() uses the build-time SYSCONFDIR directly. On Sat, Jan 03, 2015 at 05:33:32PM -0500, Tom Lane wrote: > I'd suggest wording along the lines of > > ... or it can be a system-wide file, which is named > <filename>pg_service.conf</filename> and located in the directory > specified by the environment variable <envar>PGSYSCONFDIR</envar>. > If that variable is not set, the system-wide file is sought in the > directory displayed by <command>pg_config --sysconfig</command> > (by default, <filename><replaceable>installprefix</>/etc</filename>). The default sysconfdir is more complicated; see Makefile.global.in. With a prefix of /usr/local/pgsql, the default sysconfdir is /usr/local/pgsql/etc. With a prefix of /usr/local, it is /usr/local/etc/postgresql. In the minor nit department, the term "installprefix" is heretofore unattested in our source tree. > However, I don't know whether that advice also works for Windows; > can anyone check? More or less. I haven't tested, but I have no reason to suspect the relevant parseServiceInfo() code behaves any differently. However, the value of SYSCONFDIR is different depending on your choice of libpq build system: gmake: same as non-Windows gmake build, based on "configure" arguments src/tools/msvc: #define SYSCONFDIR "/etc" win32.mak: #define SYSCONFDIR "" bcc32.mak: #define SYSCONFDIR "" A src/tools/msvc build, the most common case, would look relative to the root of the current drive, e.g. X:/etc/pg_service.conf. Borland and nmake builds would look for X:/pg_service.conf. (I doubt that reflects a coherent plan, though I can't think of a single clearly-better location known at build time.)
Noah Misch <noah@leadboat.com> writes:
> On Sat, Jan 03, 2015 at 02:36:50PM -0500, Noah Misch wrote:
>> The directory libpq consults is `pg_config --sysconfdir`
> I was wrong there. `pg_config --sysconfig` uses get_etc_path(), which adjusts
> to post-installation moves of the installation tree. parseServiceInfo() uses
> the build-time SYSCONFDIR directly.
Ugh. That makes things messy. Still, we're probably better off
recommending `pg_config --sysconfdir` than anything else. I doubt
that the theoretical ability to do a post-installation move is used
much, and it's certainly not used by people using a prepackaged build.
So the recommendation would only be wrong for someone who had done such
a move manually, and they'd probably know what to do anyway.
> On Sat, Jan 03, 2015 at 05:33:32PM -0500, Tom Lane wrote:
>> I'd suggest wording along the lines of
>> ... or it can be a system-wide file, which is named
>> <filename>pg_service.conf</filename> and located in the directory
>> specified by the environment variable <envar>PGSYSCONFDIR</envar>.
>> If that variable is not set, the system-wide file is sought in the
>> directory displayed by <command>pg_config --sysconfig</command>
>> (by default, <filename><replaceable>installprefix</>/etc</filename>).
> The default sysconfdir is more complicated; see Makefile.global.in. With a
> prefix of /usr/local/pgsql, the default sysconfdir is /usr/local/pgsql/etc.
> With a prefix of /usr/local, it is /usr/local/etc/postgresql. In the minor
> nit department, the term "installprefix" is heretofore unattested in our
> source tree.
Good point. I'd be satisfied with leaving out the parenthetical remark
altogether.
> More or less. I haven't tested, but I have no reason to suspect the relevant
> parseServiceInfo() code behaves any differently. However, the value of
> SYSCONFDIR is different depending on your choice of libpq build system:
> gmake: same as non-Windows gmake build, based on "configure" arguments
> src/tools/msvc: #define SYSCONFDIR "/etc"
> win32.mak: #define SYSCONFDIR ""
> bcc32.mak: #define SYSCONFDIR ""
> A src/tools/msvc build, the most common case, would look relative to the root
> of the current drive, e.g. X:/etc/pg_service.conf. Borland and nmake builds
> would look for X:/pg_service.conf. (I doubt that reflects a coherent plan,
> though I can't think of a single clearly-better location known at build time.)
Yeah. We should make those builds all consistent IMO; the /etc case is
probably the best one to standardize on.
regards, tom lane
On Sat, Jan 03, 2015 at 07:56:06PM -0500, Tom Lane wrote: > Noah Misch <noah@leadboat.com> writes: > > On Sat, Jan 03, 2015 at 02:36:50PM -0500, Noah Misch wrote: > >> The directory libpq consults is `pg_config --sysconfdir` > > > I was wrong there. `pg_config --sysconfig` uses get_etc_path(), which adjusts > > to post-installation moves of the installation tree. parseServiceInfo() uses > > the build-time SYSCONFDIR directly. > > Ugh. That makes things messy. Still, we're probably better off > recommending `pg_config --sysconfdir` than anything else. Agreed; I can't see to do better. > I doubt > that the theoretical ability to do a post-installation move is used > much, and it's certainly not used by people using a prepackaged build. > So the recommendation would only be wrong for someone who had done such > a move manually, and they'd probably know what to do anyway. Relocatability sees regular use in binary distributions that target multiple OS flavors. Installers available under the various "Graphical installer" headings on our download pages do rely on it, and I bet Postgres.app does likewise. All src/tools/msvc builds rely on it. To add yet more to the mess, set_pglocale_pgservice() usually sets the PGSYSCONFDIR environment variable to the result of get_etc_path(). As a result, the client programs we ship do in practice use the relocation-aware `pg_config --sysconfdir`. Third-party client programs do not. I'm comfortable writing off that discrepancy as a limitation of such packaging strategies. A packager wishing to compensate can make its installer write out an environment script that sets PGSYSCONFDIR and encourage users to source that script before starting libpq applications. I bet some installers already do that for variables like LD_LIBRARY_PATH, in which case it's an easy addition. > > More or less. I haven't tested, but I have no reason to suspect the relevant > > parseServiceInfo() code behaves any differently. However, the value of > > SYSCONFDIR is different depending on your choice of libpq build system: > > > gmake: same as non-Windows gmake build, based on "configure" arguments > > src/tools/msvc: #define SYSCONFDIR "/etc" > > win32.mak: #define SYSCONFDIR "" > > bcc32.mak: #define SYSCONFDIR "" > > > A src/tools/msvc build, the most common case, would look relative to the root > > of the current drive, e.g. X:/etc/pg_service.conf. Borland and nmake builds > > would look for X:/pg_service.conf. (I doubt that reflects a coherent plan, > > though I can't think of a single clearly-better location known at build time.) > > Yeah. We should make those builds all consistent IMO; the /etc case is > probably the best one to standardize on. Not the gmake/MinGW build, but one could make a fair argument for changing win32.mak and bcc32.mak. If we were just now adding them for the first time, we would certainly have them mimic src/tools/msvc. I have no idea who uses those alternative libpq build systems these days. I don't know whether that audience prefers compatibility with src/tools/msvc or compatibility with 9.4 and earlier of the same build system. So, while I too first thought to make them consistent, I'll demur.
On 1/3/15 7:56 PM, Tom Lane wrote: > Noah Misch <noah@leadboat.com> writes: >> On Sat, Jan 03, 2015 at 02:36:50PM -0500, Noah Misch wrote: >>> The directory libpq consults is `pg_config --sysconfdir` > >> I was wrong there. `pg_config --sysconfig` uses get_etc_path(), which adjusts >> to post-installation moves of the installation tree. parseServiceInfo() uses >> the build-time SYSCONFDIR directly. > > Ugh. That makes things messy. Still, we're probably better off > recommending `pg_config --sysconfdir` than anything else. I doubt > that the theoretical ability to do a post-installation move is used > much, and it's certainly not used by people using a prepackaged build. > So the recommendation would only be wrong for someone who had done such > a move manually, and they'd probably know what to do anyway. At least writing `pg_config --sysconfdir` indicates that it's in an installation-specific location, whereas hardcoding /etc will create confusion when it's not actually there. (Incidentally, we use /usr/local/pgsql/etc elsewhere in the documentation as a sample location.) I propose the attached patch.
Вложения
Peter Eisentraut <peter_e@gmx.net> writes:
> At least writing `pg_config --sysconfdir` indicates that it's in an
> installation-specific location, whereas hardcoding /etc will create
> confusion when it's not actually there. (Incidentally, we use
> /usr/local/pgsql/etc elsewhere in the documentation as a sample location.)
> I propose the attached patch.
Works for me --- it's at least an improvement over what's there.
regards, tom lane
On Sun, Feb 01, 2015 at 10:50:24AM -0500, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > At least writing `pg_config --sysconfdir` indicates that it's in an > > installation-specific location, whereas hardcoding /etc will create > > confusion when it's not actually there. (Incidentally, we use > > /usr/local/pgsql/etc elsewhere in the documentation as a sample location.) > > > I propose the attached patch. > > Works for me --- it's at least an improvement over what's there. +1
On Sun, Feb 1, 2015 at 9:14 PM, Noah Misch <noah@leadboat.com> wrote:
+1On Sun, Feb 01, 2015 at 10:50:24AM -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > At least writing `pg_config --sysconfdir` indicates that it's in an
> > installation-specific location, whereas hardcoding /etc will create
> > confusion when it's not actually there. (Incidentally, we use
> > /usr/local/pgsql/etc elsewhere in the documentation as a sample location.)
>
> > I propose the attached patch.
>
> Works for me --- it's at least an improvement over what's there.