Re: default_table_access_method is not in sample config file

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