Thread: Sample configuration files
We have sample configuration files for postgresql.conf and recovery.conf, but we do not have them for contrib modules. This patch attempts to add them. Although the patch puts the sample configuration files in the tree, it doesn't try to install them. That's partly because I think it would need an extension version bump and that doesn't seem worth it. Also, while writing this patch, it crossed my mind that the plpgsql variables should probably be in the main postgresql.conf file because we install it by default. I will happily write that patch if desired, independently of this patch. Current as of 26fa446, added to next commitfest. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Attachment
On Mon, Aug 29, 2016 at 7:04 AM, Vik Fearing <vik@2ndquadrant.fr> wrote: > We have sample configuration files for postgresql.conf and > recovery.conf, but we do not have them for contrib modules. This patch > attempts to add them. > > Although the patch puts the sample configuration files in the tree, it > doesn't try to install them. That's partly because I think it would > need an extension version bump and that doesn't seem worth it. > What is the use case and how these files suppose to work? Do you expect these to be loaded as we do for postgresql.conf? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
On Mon, Aug 29, 2016 at 7:04 AM, Vik Fearing <vik@2ndquadrant.fr> wrote: > We have sample configuration files for postgresql.conf and > recovery.conf, but we do not have them for contrib modules. This patch > attempts to add them. > > Although the patch puts the sample configuration files in the tree, it > doesn't try to install them. That's partly because I think it would > need an extension version bump and that doesn't seem worth it. I don't think that would need an extension version bump; we only need that if we're changing which SQL objects get created. So my opinion of this effort is: 1. If we're going to add these files, there's no reason not to install them; in fact, not installing them makes the whole thing rather pointless, as most people will only see the stuff that gets installed, not uninstalled files in the source tree. 2. But I'm not sure that this will actually be useful to people. It seems like it might just be one more thing for patch authors to maintain. I think that if somebody wants to set a parameter defined for a contrib module, it's easy enough to just add an entry into postgresql.conf, or use ALTER SYSTEM .. SET. Going and finding the sample file (which only sets the value to the default) and then putting that into your postgresql.conf seems like an extra step. Of course, others may feel differently and that is fine... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 09/02/2016 08:58 AM, Robert Haas wrote: > On Mon, Aug 29, 2016 at 7:04 AM, Vik Fearing <vik@2ndquadrant.fr> wrote: >> We have sample configuration files for postgresql.conf and >> recovery.conf, but we do not have them for contrib modules. This patch >> attempts to add them. >> >> Although the patch puts the sample configuration files in the tree, it >> doesn't try to install them. That's partly because I think it would >> need an extension version bump and that doesn't seem worth it. > > I don't think that would need an extension version bump; we only need > that if we're changing which SQL objects get created. So my opinion > of this effort is: > > 1. If we're going to add these files, there's no reason not to install > them; in fact, not installing them makes the whole thing rather > pointless, as most people will only see the stuff that gets installed, > not uninstalled files in the source tree. Fair enough. The alternative is for packagers to install them, like they do for recovery.conf.sample. I'll update the patch as soon as we get consensus that this is wanted. > 2. But I'm not sure that this will actually be useful to people. It > seems like it might just be one more thing for patch authors to > maintain. I think that if somebody wants to set a parameter defined > for a contrib module, it's easy enough to just add an entry into > postgresql.conf, or use ALTER SYSTEM .. SET. Going and finding the > sample file (which only sets the value to the default) and then > putting that into your postgresql.conf seems like an extra step. I was imagining just using the "include" directive. I have heard the desire for annotated sample conf files for the contrib modules twice now from different people which is why I wrote the patch. If we decide that the extra documentation is too much of a burden, I can understand that, also. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
El 02/09/16 a las 04:19, Vik Fearing escribió: > >> 2. But I'm not sure that this will actually be useful to people. It >> seems like it might just be one more thing for patch authors to >> maintain. I think that if somebody wants to set a parameter defined >> for a contrib module, it's easy enough to just add an entry into >> postgresql.conf, or use ALTER SYSTEM .. SET. Going and finding the >> sample file (which only sets the value to the default) and then >> putting that into your postgresql.conf seems like an extra step. > > I was imagining just using the "include" directive. I have heard the > desire for annotated sample conf files for the contrib modules twice now > from different people which is why I wrote the patch. If we decide that > the extra documentation is too much of a burden, I can understand that, > also. I think having a sample configuration file which we can include and make the specific configuration changes for that contrib has it's logic, and I believe it's a good idea to include. We suggest having a bdr.conf file separated with all the BDR configuration parameters, so this makes total sense. I will have a better check at the patch and get back (didn't find anything wrong at the first look at it). Regards, -- Martín Marqués http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 08/29/2016 03:34 AM, Vik Fearing wrote: > We have sample configuration files for postgresql.conf and > recovery.conf, but we do not have them for contrib modules. This patch > attempts to add them. > > Although the patch puts the sample configuration files in the tree, it > doesn't try to install them. That's partly because I think it would > need an extension version bump and that doesn't seem worth it. > > Also, while writing this patch, it crossed my mind that the plpgsql > variables should probably be in the main postgresql.conf file because we > install it by default. I will happily write that patch if desired, > independently of this patch. > > Current as of 26fa446, added to next commitfest. I noticed that this patch has been marked Waiting on Author with no comment. Peter, what more should I be doing right now while waiting for Martín's review? -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Vik Fearing <vik@2ndquadrant.fr> writes:
> I noticed that this patch has been marked Waiting on Author with no
> comment. Peter, what more should I be doing right now while waiting for
> Martín's review?
FWIW, I agree with the upthread misgivings about whether this is actually
a useful effort. Even if we installed the sample config files somewhere
(something there is not consensus for AFAICT), they would not actually
*do* anything useful as standalone files. I suppose you are imagining
that people would either manually concatenate them onto postgresql.conf
or insert an include directive for them into postgresql.conf, but neither
of those things sound pleasant or maintainable.
Moreover, it's not clear why anyone would do that at all in the age of
ALTER SYSTEM SET.
I suggest that it'd be more fruitful to view this as a documentation
effort; that is, in each contrib module's SGML documentation file provide
a standardized section listing all its parameters and their default
settings. That would be something that could be copied-and-pasted from
into either an editor window on postgresql.conf for the old guard, or
an ALTER SYSTEM SET command for the new.
regards, tom lane
On Thu, Sep 8, 2016 at 8:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Vik Fearing <vik@2ndquadrant.fr> writes: >> I noticed that this patch has been marked Waiting on Author with no >> comment. Peter, what more should I be doing right now while waiting for >> Martín's review? > > FWIW, I agree with the upthread misgivings about whether this is actually > a useful effort. Even if we installed the sample config files somewhere > (something there is not consensus for AFAICT), they would not actually > *do* anything useful as standalone files. I suppose you are imagining > that people would either manually concatenate them onto postgresql.conf > or insert an include directive for them into postgresql.conf, but neither > of those things sound pleasant or maintainable. > > Moreover, it's not clear why anyone would do that at all in the age of > ALTER SYSTEM SET. > > I suggest that it'd be more fruitful to view this as a documentation > effort; that is, in each contrib module's SGML documentation file provide > a standardized section listing all its parameters and their default > settings. That would be something that could be copied-and-pasted from > into either an editor window on postgresql.conf for the old guard, or > an ALTER SYSTEM SET command for the new. So, tallying up the votes, one person has spoken in favor of this (Martín Marqués) and two against it (Tom Lane and Robert Haas). One presumes the author is also in favor, so that's a 2-2 tie. That's not exactly a consensus against this effort, but it's not a ringing endorsement, either. It's hard for me to imagine anything getting committed here unless some more people think it's a good idea. So, anyone else have an opinion, pro or con? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Sep 29, 2016 at 2:25 AM, Robert Haas <robertmhaas@gmail.com> wrote: > So, anyone else have an opinion, pro or con? Going through this thread, I'd vote -1. This is a documentation effort mainly, and installing those files has zero effect if they are not loaded via include_if_exists or include in postgresql.conf. -- Michael
On 09/29/2016 05:55 AM, Michael Paquier wrote: > On Thu, Sep 29, 2016 at 2:25 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> So, anyone else have an opinion, pro or con? > > Going through this thread, I'd vote -1. This is a documentation effort > mainly, and installing those files has zero effect if they are not > loaded via include_if_exists or include in postgresql.conf. Just the other day, I needed this patch yet again but had to go look up the documentation instead. I wonder if it would be a good idea to have a postgresql.conf.d directory that postgresql.conf would include_dir by default. These could then live in there and all I would have had to do is uncomment the values I wanted. This patch doesn't do that, of course, but I could easily write a patch that does. Would that go over better with the -1ers? -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Thu, Sep 29, 2016 at 2:50 PM, Vik Fearing <vik@2ndquadrant.fr> wrote: > I wonder if it would be a good idea to have a postgresql.conf.d > directory that postgresql.conf would include_dir by default. These > could then live in there and all I would have had to do is uncomment the > values I wanted. This has more potential. And allow extensions to install config files in share/config/, not necessarily as .sample files, but you imply it I guess. > This patch doesn't do that, of course, but I could easily write a patch > that does. Would that go over better with the -1ers? For now I have changed the patch as returned with feedback, the CF is wrapping up. -- Michael