On 2019-08-13 15:03:13 +0900, Michael Paquier wrote:
> On Fri, Aug 09, 2019 at 11:34:05AM +0300, Heikki Linnakangas wrote:
> > On 11/04/2019 19:49, Andres Freund wrote:
> >> Hm, I think we should rather add it to sample. That's an oversight, not
> >> intentional.
> > 
> > I just noticed that this is still an issue. default_table_access_method is
> > not in the sample config file, and it's not marked with GUC_NOT_IN_SAMPLE.
> > I'll add this to the open items list so we don't forget.

Thanks!


> I think that we should give it the same visibility as default_tablespace,
> so adding it to the sample file sounds good to me.

> diff --git a/src/backend/utils/misc/postgresql.conf.sample 
> b/src/backend/utils/misc/postgresql.conf.sample
> index 65a6da18b3..39fc787851 100644
> --- a/src/backend/utils/misc/postgresql.conf.sample
> +++ b/src/backend/utils/misc/postgresql.conf.sample
> @@ -622,6 +622,7 @@
>  #default_tablespace = ''             # a tablespace name, '' uses the default
>  #temp_tablespaces = ''                       # a list of tablespace names, 
> '' uses
>                                       # only default tablespace
> +#default_table_access_method = 'heap'

Pushed, thanks.


>  #check_function_bodies = on
>  #default_transaction_isolation = 'read committed'
>  #default_transaction_read_only = off

Hm.  I find the current ordering there a bit weird. Unrelated to your
proposed change.  The header of the group is

#------------------------------------------------------------------------------
# CLIENT CONNECTION DEFAULTS
#------------------------------------------------------------------------------

# - Statement Behavior -

but I don't quite see GUCs like default_tablespace, search_path (due to
determining a created table's schema), temp_tablespace,
default_table_access_method fit reasonably well under that heading. They
all can affect persistent state. That seems pretty different from a
number of other settings (client_min_messages,
default_transaction_isolation, lock_timeout, ...) which only have
transient effects.

Should we perhaps split that group? Not that I have a good proposal for
better names.

Greetings,

Andres Freund


Reply via email to