GUC and postgresql.conf docs

Josh Berkus <josh@agliodbs.com> writes:

Can I aassume that any setting documented under "3.4. Run-time Configuration"
is a GUC variable modifiable through a SET statement? If not, where can I
find documenation on which .conf settings are GUC variables and which are
not?

Use the source, Luke.

The tables in src/backend/utils/misc/guc.c are the authoritative reference.
Read the comments in src/include/utils/guc.h first.

Yes, everything in postgresql.conf is a GUC variable; but I think there
may be some GUC variables that were omitted from postgresql.conf.
Hopefully intentionally, not by oversight ...

regards, tom lane

Tom,

The tables in src/backend/utils/misc/guc.c are the authoritative reference.
Read the comments in src/include/utils/guc.h first.

Thanks. Would never have found it on my own ...

Yes, everything in postgresql.conf is a GUC variable; but I think there
may be some GUC variables that were omitted from postgresql.conf.
Hopefully intentionally, not by oversight ...

Mmm? I think I have some terminology confusion somewhere. I thought that a
GUC variable meant that it could be changed through a SET statement. But
some settings, like TCP/IP socket, cannot be SET. What distinguises
settings that can be SET from GUC variables that are restart-only?

I sense more posts to the list in the offing.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus writes:

Can I aassume that any setting documented under "3.4. Run-time Configuration"
is a GUC variable

Yes, although "GUC" is not an official term that is defined anywhere.

modifiable through a SET statement?

No, some of them say that they can only be set at server start. But you
can run SHOW on all of them.

--
Peter Eisentraut peter_e@gmx.net

Josh Berkus <josh@agliodbs.com> writes:

What distinguises
settings that can be SET from GUC variables that are restart-only?

The PGC_CONTEXT settings. Go back and read those comments I pointed
you to.

regards, tom lane

Tom, Peter,

Since I had to do this anyway, I thought the following would help you clean up
a little. Please check my report for accuracy; postgresql.conf.sample lists
the GUC variables in one order, the online documentation in another, and
guc.c in a third, completely different order. So it's entirely possible I
missed something.

BTW, my next proposal after finishing this list will be to re-order the
variables in postgresql.conf.sample into something more logical than the
current "incremental development order". Expect it next week.

GUC Options with no documentation:
The following options exist in postgresql.conf.sample and in guc.c but not in
the online documenation anywhere the search box can find:

trace_locks
trace_userlocks
trace_lwlocks
debug_deadlocks
trace_lock_oidmin
trace_lock_table

show_btree_build_stats

Defined in guc.c but not in PostgreSQL.conf or docs:
The following four GUC variables are defined in guc.c, but are not included in
postgresql.conf.sample, and do not show up in the online docs under anything
I can search on. Do they do anything? If so, what?

{"fixbtree", PGC_POSTMASTER}, &FixBTree,
true, NULL, NULL
{"pre_auth_delay", PGC_SIGHUP}, &PreAuthDelay,
0, 0, 60, NULL, NULL
{"server_encoding", PGC_USERSET}, &server_encoding_string,
"SQL_ASCII", assign_server_encoding, show_server_encoding
{"session_authorization", PGC_USERSET, GUC_NO_SHOW_ALL | GUC_NO_RESET_ALL},
&session_authorization_string,
NULL, assign_session_authorization, show_session_authorization

Defined in guc.c and docs but not in postgresql.conf:
These four related settings are defined guc's that somehow made it into the
docs but not into postgresql.conf.sample:

{"lc_messages", PGC_SUSET}, &locale_messages,
"", locale_messages_assign, NULL

{"lc_monetary", PGC_USERSET}, &locale_monetary,
"C", locale_monetary_assign, NULL

{"lc_numeric", PGC_USERSET}, &locale_numeric,
"C", locale_numeric_assign, NULL

{"lc_time", PGC_USERSET}, &locale_time,
"C", locale_time_assign, NULL

Hope that helps clean up for the next release!

--
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus <josh@agliodbs.com> writes:

GUC Options with no documentation:
The following options exist in postgresql.conf.sample and in guc.c but not in
the online documenation anywhere the search box can find:

trace_locks
trace_userlocks
trace_lwlocks
debug_deadlocks
trace_lock_oidmin
trace_lock_table
show_btree_build_stats

These are all debugging options that probably don't need to be in the
user documentation (ie, if you aren't familiar enough with the source
code to find out about 'em from there, you do not need them and should
probably not be messing with 'em --- in fact, many of them don't even
exist except in specially-hacked builds). I'd vote for taking them out
of postgresql.conf.sample, I think.

The following four GUC variables are defined in guc.c, but are not included in
postgresql.conf.sample, and do not show up in the online docs under anything
I can search on. Do they do anything? If so, what?

{"fixbtree", PGC_POSTMASTER}, &FixBTree,
true, NULL, NULL

This one is gone anyway in CVS tip.

{"pre_auth_delay", PGC_SIGHUP}, &PreAuthDelay,
0, 0, 60, NULL, NULL

This is another debugging option of rather questionable general
usefulness.

{"server_encoding", PGC_USERSET}, &server_encoding_string,
"SQL_ASCII", assign_server_encoding, show_server_encoding

I'm not sure why this one is marked PGC_USERSET --- seems like it should
not be possible to override it from SET. It should be documented as a
read-only option, I think. (Looks ... actually it is set up that way
in CVS tip.)

{"session_authorization", PGC_USERSET, GUC_NO_SHOW_ALL | GUC_NO_RESET_ALL},
&session_authorization_string,
NULL, assign_session_authorization, show_session_authorization

This one makes no sense to set in postgresql.conf, certainly. Not sure
how the docs ought to describe it.

These four related settings are defined guc's that somehow made it into the
docs but not into postgresql.conf.sample:

{"lc_messages", PGC_SUSET}, &locale_messages,
"", locale_messages_assign, NULL
{"lc_monetary", PGC_USERSET}, &locale_monetary,
"C", locale_monetary_assign, NULL
{"lc_numeric", PGC_USERSET}, &locale_numeric,
"C", locale_numeric_assign, NULL
{"lc_time", PGC_USERSET}, &locale_time,
"C", locale_time_assign, NULL

These guys are added to postgresql.conf by initdb, so I think that's
okay. But perhaps that process could be documented better.

regards, tom lane

Tom Lane writes:

{"server_encoding", PGC_USERSET}, &server_encoding_string,
"SQL_ASCII", assign_server_encoding, show_server_encoding

I'm not sure why this one is marked PGC_USERSET --- seems like it should
not be possible to override it from SET. It should be documented as a
read-only option, I think. (Looks ... actually it is set up that way
in CVS tip.)

Do we even need this one? If you want to find out the server encoding
(which should be rare anyway), you can select it from pg_database.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

{"server_encoding", PGC_USERSET}, &server_encoding_string,
"SQL_ASCII", assign_server_encoding, show_server_encoding

Do we even need this one? If you want to find out the server encoding
(which should be rare anyway), you can select it from pg_database.

This is now in the same class as server_version, i.e., it's a read-only
GUC variable. I did it that way so that these values could be
transmitted to the frontend via the new 3.0 protocol's ParameterStatus
mechanism.

I know we have a difference of opinion about the cleanliness of
read-only "variables", but I think it's a reasonable approach to take.
It certainly beats inventing a mechanism that duplicates the display
portions of GUC. For instance, isn't "show lc_collate" a lot better
than having to run pg_controldata to find out the database locale?

regards, tom lane

Tom Lane writes:

This is now in the same class as server_version, i.e., it's a read-only
GUC variable. I did it that way so that these values could be
transmitted to the frontend via the new 3.0 protocol's ParameterStatus
mechanism.

Do we need to communicate the server encoding during any part of the
protocol? ISTM that the server encoding shouldn't ever be needed by a
client for computation, except out of pure interest.

For instance, isn't "show lc_collate" a lot better than having to run
pg_controldata to find out the database locale?

No, because you would like to be able to see it inside an SQL session.
But the server encoding can already be fetched inside an SQL session from
the official source. A read-only parameter to make this information
available in a different way just seems wasteful. We don't have read-only
parameters for any of the other columns in pg_database either.

--
Peter Eisentraut peter_e@gmx.net

Guys,

One dumb question:

What numbers are INT_MAX and DBL_MAX in C?

--
Josh Berkus
Aglio Database Solutions
San Francisco

--On Tuesday, May 13, 2003 09:16:44 -0700 Josh Berkus <josh@agliodbs.com>
wrote:

Guys,

One dumb question:

What numbers are INT_MAX and DBL_MAX in C?

The maximum for that type that can be represented. It's platform dependent.

on FreeBSD 4:
#define INT_MAX 0x7fffffff /* max value for an int */
#define DBL_MAX 1.7976931348623157E+308

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Peter Eisentraut <peter_e@gmx.net> writes:

Do we need to communicate the server encoding during any part of the
protocol?

Probably. What if the client needs to know what is the set of
characters that can actually be stored in the database? client_encoding
doesn't tell you the whole truth on that. I'm also still unconvinced
that binary data I/O should perform encoding conversion (it does as of
CVS tip, but I'm not 100% sold that that's the right choice).

But the server encoding can already be fetched inside an SQL session from
the official source.

... if you know where to look for it, and if you know that you are not
currently in an aborted transaction, and probably a few other "if's".

A read-only parameter to make this information
available in a different way just seems wasteful.

It is duplicative to a certain extent, but the point is to make life
easier for client libraries. See past discussions with Barry Lind in
particular. The general mechanism seems necessary in any case, and
once we have it, applying it to these particular values isn't adding
much bloat.

regards, tom lane

Tom Lane writes:

Do we need to communicate the server encoding during any part of the
protocol?

Probably. What if the client needs to know what is the set of
characters that can actually be stored in the database?

That sort of thing might be interesting to know, but it does not seem to
be part of the protocol.

Anyway, you cannot answer that question reliably by looking at the server
encoding. You need to know which conversion will be invoked and what that
conversion will do, and that is a lot harder to do programmatically.

I'm also still unconvinced that binary data I/O should perform encoding
conversion (it does as of CVS tip, but I'm not 100% sold that that's the
right choice).

That depends on what you intend to achieve with the binary format. For
some of the numeric types it's obvious, but for strings it's not.

The general mechanism seems necessary in any case, and once we have it,
applying it to these particular values isn't adding much bloat.

But where does it stop? What's the criterion?

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane writes:

I'm also still unconvinced that binary data I/O should perform encoding
conversion (it does as of CVS tip, but I'm not 100% sold that that's the
right choice).

That depends on what you intend to achieve with the binary format. For
some of the numeric types it's obvious, but for strings it's not.

Sorry if I wasn't clear. Binary-encoded numeric values don't go through
encoding conversion. Text strings currently do. The only place where I
had any difficulty deciding what a particular datatype should do is with
the 1-byte "char" type, which has a foot in both camps. I decided to
treat it as an unconverted single byte (but am willing to listen to
argument if anyone thinks differently).

The general mechanism seems necessary in any case, and once we have it,
applying it to these particular values isn't adding much bloat.

But where does it stop? What's the criterion?

Usefulness to client libraries, I think. If anyone pops up and says "my
library really needs to know the value of setting X", I'm happy to add X
to the set of values reported by ParameterStatus. If that set starts to
get large then I'd be willing to think about making it
run-time-configurable --- the only reason it isn't already is we don't
have enough examples to prove the need.

regards, tom lane

Tom, Peter,

While I'm writing this guide ... where does PostgreSQL store temp files for
queires which are too large for sort_mem? I can't seem to find docs on
this.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus <josh@agliodbs.com> writes:

While I'm writing this guide ... where does PostgreSQL store temp files for
queires which are too large for sort_mem?

Each database has a temp directory. I think it's called
$PGDATA/base/DBOID/pgsql_tmp. You can replace that subdirectory by a
symlink if you want to put temp files someplace else.

regards, tom lane

Binary-encoded numeric values don't go through
encoding conversion. Text strings currently do. The only place where I
had any difficulty deciding what a particular datatype should do is with
the 1-byte "char" type, which has a foot in both camps. I decided to
treat it as an unconverted single byte (but am willing to listen to
argument if anyone thinks differently).

One concern I would have is how to get at the raw unconverted text data
without changing the client encoding. I do not really see an advantage in
providing the same thing for text and binary format if it is now
a per column thing. I would do text unconverted if binary format is selected
for that column.

Did COPY BINARY convert text ?

Andreas

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:

Binary-encoded numeric values don't go through
encoding conversion. Text strings currently do. The only place where I
had any difficulty deciding what a particular datatype should do is with
the 1-byte "char" type, which has a foot in both camps. I decided to
treat it as an unconverted single byte (but am willing to listen to
argument if anyone thinks differently).

One concern I would have is how to get at the raw unconverted text data
without changing the client encoding. I do not really see an advantage in
providing the same thing for text and binary format if it is now
a per column thing. I would do text unconverted if binary format is
selected for that column.

That's a good point: as things currently stand in CVS tip, there's
really no difference between text and binary output of textual
datatypes. Perhaps that's how it should be, but one could make an
argument that we're missing a chance to expose possibly-useful
functionality.

Did COPY BINARY convert text ?

COPY BINARY currently does the same conversions as binary I/O to the
client. This is arguably reasonable when doing COPY to/from the
frontend, but it's probably not very reasonable when doing COPY to/from
a file in the server's filesystem --- there's no obvious reason why that
should be affected by client_encoding. And yet, I'm not sure the cases
should be different either. Wouldn't it be a bad thing if a COPY dump
made through psql's \copy didn't reload correctly through "COPY FROM
file"?

We could sidestep that issue if binary I/O for text was in server
encoding in all cases.

regards, tom lane

We could sidestep that issue if binary I/O for text was in server
encoding in all cases.

I think that would be reasonable, yes. After all one argument for using
binary mode is speed and efficiency, and not it's editability with
a text editor.

Andreas