Re: list append syntax for postgresql.conf
On 2019-02-21 18:18, Robert Haas wrote: > Another off-ball idea is to maybe allow something like > shared_preload_statements.pg_stat_statments = 1. The server would > load all libraries X for which shared_preload_statements.X is set to a > value that is one of the ways we spell a true value for a Boolean GUC. This line of thought is attractive, but the library lists can be order-sensitive in case of cooperating libraries, so an approach were the load order is indeterminate might not work. (It might be worth exploring ways of making it not order-sensitive. Many trade-offs.) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: list append syntax for postgresql.conf
Robert Haas writes: > I like the idea of solving this problem but I'm not sure it's a good > idea to add this sort of syntax to postgresql.conf. I think it would > be more useful to provide a way to tell ALTER SYSTEM that you want to > append rather than replace, as I see Euler also proposes. > Another off-ball idea is to maybe allow something like > shared_preload_statements.pg_stat_statments = 1. The server would > load all libraries X for which shared_preload_statements.X is set to a > value that is one of the ways we spell a true value for a Boolean GUC. Either one of these would avoid the problem of having more than one place-of-definition of a GUC value, so I find them attractive. The second one seems a tad more modular, perhaps, and it's also easier to figure out how to undo a change. A possible objection to the second one is that it binds us forevermore to allowing setting of GUCs that weren't previously known, which is something I don't much care for. But it can probably be constrained enough to remove the formal indeterminacy: we can insist that all GUCs named "shared_preload_modules.something" will be booleans, and then we'll throw error if any of them don't correspond to a known loadable library. regards, tom lane
Re: list append syntax for postgresql.conf
On Wed, Feb 20, 2019 at 10:15 AM Peter Eisentraut wrote: > Nowadays there are a number of methods for composing multiple > postgresql.conf files for modularity. But if you have a bunch of things > you want to load via shared_preload_libraries, you have to put them all > in one setting. How about some kind of syntax for appending something > to a list, like > > shared_preload_libraries += 'pg_stat_statements' > > Thoughts? I like the idea of solving this problem but I'm not sure it's a good idea to add this sort of syntax to postgresql.conf. I think it would be more useful to provide a way to tell ALTER SYSTEM that you want to append rather than replace, as I see Euler also proposes. Another off-ball idea is to maybe allow something like shared_preload_statements.pg_stat_statments = 1. The server would load all libraries X for which shared_preload_statements.X is set to a value that is one of the ways we spell a true value for a Boolean GUC. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: list append syntax for postgresql.conf
Peter Eisentraut writes: > Nowadays there are a number of methods for composing multiple > postgresql.conf files for modularity. But if you have a bunch of things > you want to load via shared_preload_libraries, you have to put them all > in one setting. How about some kind of syntax for appending something > to a list, like > shared_preload_libraries += 'pg_stat_statements' Seems potentially useful, but you'd need to figure out how to represent this in the pg_settings and pg_file_settings views, which currently suppose that any given GUC's value is determined by exactly one place in the config file(s). regards, tom lane
Re: list append syntax for postgresql.conf
On 2/20/19 10:54 AM, Joe Conway wrote: >> shared_preload_libraries += 'pg_stat_statements' > > I like the idea, but presume it would apply to any GUC list, not just > shared_preload_libraries? It would be nice if there were some way for extensions to declare GUC lists (the very thing that recently became explicitly unsupported). The difficulty seems to be that a GUC may be assigned before the extension has been loaded to determine whether list syntax should apply. Could a change like this improve that situation too, perhaps by deciding that += syntax /implies/ that an as-yet-undeclared GUC is to be of list form (which could then be checked when the extension declares the GUC)? -Chap
Re: list append syntax for postgresql.conf
On Wednesday, February 20, 2019, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > Nowadays there are a number of methods for composing multiple > postgresql.conf files for modularity. But if you have a bunch of things > you want to load via shared_preload_libraries, you have to put them all > in one setting. How about some kind of syntax for appending something > to a list, like > > shared_preload_libraries += 'pg_stat_statements' > I would rather just have the behavior for that variable “append mode”, period. Maybe do it generally for all multi-value variables. It would be like “add only” permissions - if you don’t want something loaded it cannot be specified ever, overwrite is not allowed. Get rid of any order-of-operations concerns. David J.
Re: list append syntax for postgresql.conf
On 2/20/19 10:15 AM, Peter Eisentraut wrote: > Nowadays there are a number of methods for composing multiple > postgresql.conf files for modularity. But if you have a bunch of things > you want to load via shared_preload_libraries, you have to put them all > in one setting. How about some kind of syntax for appending something > to a list, like > > shared_preload_libraries += 'pg_stat_statements' > > Thoughts? I like the idea, but presume it would apply to any GUC list, not just shared_preload_libraries? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development signature.asc Description: OpenPGP digital signature
Re: list append syntax for postgresql.conf
Re: Peter Eisentraut 2019-02-20 <74af1f60-34af-633e-ee8a-310d40c74...@2ndquadrant.com> > Nowadays there are a number of methods for composing multiple > postgresql.conf files for modularity. But if you have a bunch of things > you want to load via shared_preload_libraries, you have to put them all > in one setting. How about some kind of syntax for appending something > to a list, like > > shared_preload_libraries += 'pg_stat_statements' I've thought about that syntax myself in the past. It would be very handy to be able to things like /etc/postgresql/11/main/conf.d/pg_stat_statements.conf: shared_preload_libraries += 'pg_stat_statements' pg_stat_statements.track = all (The current Debian packages already create and support conf.d/ in the default configuration.) +1. Christoph
Re: list append syntax for postgresql.conf
Em qua, 20 de fev de 2019 às 12:15, Peter Eisentraut escreveu: > > Nowadays there are a number of methods for composing multiple > postgresql.conf files for modularity. But if you have a bunch of things > you want to load via shared_preload_libraries, you have to put them all > in one setting. How about some kind of syntax for appending something > to a list, like > Partial setting could confuse users, no? I see the usefulness of such feature but I prefer to implement it via ALTER SYSTEM. Instead of += I prefer to add another option to ALTER SYSTEM that appends new values such as: ALTER SYSTEM APPEND shared_preload_libraries TO 'pg_stat_statements, pg_prewarm'; and it will expand to: shared_preload_libraries = 'foo, bar, pg_stat_statements, pg_prewarm' > shared_preload_libraries += 'pg_stat_statements' > What happen if you have: shared_preload_libraries = 'foo' then shared_preload_libraries += 'bar' and then shared_preload_libraries = 'pg_stat_statements' You have only 'pg_stat_statements' or 'foo, bar, pg_stat_statements'? Suppose you mistype 'bar' as 'baz', do you have only 'pg_stat_statements'? -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento