Обсуждение: list append syntax for postgresql.conf

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?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Em qua, 20 de fev de 2019 às 12:15, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> 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

Re: Peter Eisentraut 2019-02-20 <74af1f60-34af-633e-ee8a-310d40c741a7@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

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

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'

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

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 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

On Wed, Feb 20, 2019 at 10:15 AM Peter Eisentraut
<peter.eisentraut@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'
>
> 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

Robert Haas <robertmhaas@gmail.com> 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

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