The relationship between 'min_wal_size', 'max_wal_size' and 'wal_segment_size' is not record.
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/bug-reporting.html Description: configuration option 'min_wal_size' and 'max_wal_size' must be at least twice 'wal_segment_size', but none of these information was mentioned in the description of these three configuration options, nor in related document in https://www.postgresql.org/docs/11/runtime-config-wal.html, https://www.postgresql.org/docs/11/runtime-config-preset.html, and https://www.postgresql.org/docs/11/wal-configuration.html. Although the default value of 'min_wal_size' and 'max_wal_size' is much larger than 'wal_segment_size', in case of some corner case, I think it is better to supplement this information in the doc.
Tips about using mount point directly as the data_directory.
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/bug-reporting.html Description: Using a mount point directly as the data_directory is not recommended, but this tip is not recorded in the doc https://www.postgresql.org/docs/11/runtime-config-file-locations.html or any where else. I suggest adding this tip in the doc when introducing configuration option 'data_directory' in https://www.postgresql.org/docs/11/runtime-config-file-locations.html.
'pg_global' cannot be used as default_tablespace.
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/bug-reporting.html Description: Tablespace 'pg_global' is one of the two auto-generated tablespace by initdb, and 'pg_global' should not be used as the default_tablespace, since it is used for shared system catalogs. However, none of these information is recorded in the doc https://www.postgresql.org/docs/11/runtime-config-client.html and https://www.postgresql.org/docs/11/manage-ag-tablespaces.html. In case of some mishandling to use 'pg_global' as a default_tablespace value, it is better to record it in the doc of https://www.postgresql.org/docs/11/manage-ag-tablespaces.html.
Re: Tips about using mount point directly as the data_directory.
On Tuesday, November 10, 2020, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/13/bug-reporting.html > Description: > > Using a mount point directly as the data_directory is not recommended, but > this tip is not recorded in the doc > https://www.postgresql.org/docs/11/runtime-config-file-locations.html or > any > where else. I suggest adding this tip in the doc when introducing > configuration option 'data_directory' in > https://www.postgresql.org/docs/11/runtime-config-file-locations.html. > A link to the spot in the documentation to where this, and other points, are discussed would probably be better. https://www.postgresql.org/docs/13/creating-cluster.html David J.
Re: What does "[backends] should seldom or never need to wait for a write to occur" mean?
On Mon, Nov 9, 2020 at 08:36:32PM -0500, Bruce Momjian wrote: > On Tue, Nov 3, 2020 at 06:11:21PM +, Chris Wilson wrote: > > Hi all, > > > > I did some more research and found this explanation in a presentation by > > 2ndQuadrant: > > > > > > When a process wants a buffer, it asks BufferAlloc for the file/block. > > If > > the block is already cached, it gets pinned and then returned. > > Otherwise, a > > new buffer must be found to hold this data. If there are no buffers free > > (there usually aren’t) BufferAlloc selects a buffer to evict to make > > space > > for the new one. If that page is dirty, it is written out to disk. This > > can > > cause the backend trying to allocate that buffer to block as it waits > > for > > that write I/O to complete. > > > > > > So it seems that both reads and writes can potentially have to wait for I/O. > > And the bgwriter reduces the risk of hitting a dirty page and needing to > > write > > it before evicting. > > > > So perhaps the documentation should say: > > > > "There is a separate server process called the background writer, whose > > function is to issue writes of “dirty” (new or modified) shared buffers. > > This reduces the chances that a backend needing an empty buffer must write a > > dirty one back to disk before evicting it." > > I think this would be a step backward. The point is to say that writes > rarely happen in the foreground, not to explain when writes do happen. > With your wording, there could be other cases where writes happen in the > foreground, and the point is they rarely happen. I thought some more about this, and it seems the problem really is that "wait for a write" is unclear, as you said. This patch fixes it by referencing "wait for such writes". -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index f043433e31..31b3ff6a20 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -2147,7 +2147,7 @@ include_dir 'conf.d' process called the background writer, whose function is to issue writes of dirty (new or modified) shared buffers. It writes shared buffers so server processes handling - user queries seldom or never need to wait for a write to occur. + user queries seldom or never need to wait for such writes to occur. However, the background writer does cause a net overall increase in I/O load, because while a repeatedly-dirtied page might otherwise be written only once per checkpoint interval, the
Re: Missing file is mentioned on page https://www.postgresql.org/docs/13/libpq-exec.html
On Fri, Oct 30, 2020 at 11:09:58AM -0400, Tom Lane wrote: > Euler Taveira writes: > > On Tue, 27 Oct 2020 at 13:54, Bruce Momjian wrote: > >> Uh, in my source tree that is a symlink to > >> src/backend/catalog/pg_type_d.h, but that file is generated by > >> src/backend/catalog/genbki.pl. Does that help you? > > > Shouldn't we replace "are defined in the file" with "are defined in the > > generated file"? That's the only place that mentions *_d.h files. Perhaps > > adding a link to BKI [1] should avoid further questions. > > It'd probably confuse users more, actually. This chapter is aimed at > users of Postgres, not developers. > > >From a user's viewpoint, catalog/pg_type_d.h should look pretty much > like any other installed header. We want to point them at that, not at > pg_type.h, because the latter is painful to include in application code > that doesn't want to buy into the Postgres programming environment > altogether. > > Thinking about it from the perspective of someone dealing with an > installation tree not a source tree, maybe the reference should > be to "server/catalog/pg_type_d.h". That might help disabuse > anyone who's expecting to find it at that path in the git tree. I am confused what the "server/" prefix means in a path name. We currently say: The OIDs of the built-in data types are defined in the file src/include/catalog/pg_type_d.h in the source tree. We could add "compiled": The OIDs of the built-in data types are defined in the file src/include/catalog/pg_type_d.h in the source tree after it is compiled. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Re: Missing file is mentioned on page https://www.postgresql.org/docs/13/libpq-exec.html
Bruce Momjian writes: > On Fri, Oct 30, 2020 at 11:09:58AM -0400, Tom Lane wrote: >> Thinking about it from the perspective of someone dealing with an >> installation tree not a source tree, maybe the reference should >> be to "server/catalog/pg_type_d.h". That might help disabuse >> anyone who's expecting to find it at that path in the git tree. > I am confused what the "server/" prefix means in a path name. That is the path underneath the installation "include" directory at which that file will be found. > We currently say: > The OIDs of the built-in data types are defined in > the file src/include/catalog/pg_type_d.h in the > source tree. Yeah, so also s/source tree/install tree/. regards, tom lane
Re: Missing file is mentioned on page https://www.postgresql.org/docs/13/libpq-exec.html
On Tue, Nov 10, 2020 at 06:15:29PM -0500, Tom Lane wrote: > Bruce Momjian writes: > > On Fri, Oct 30, 2020 at 11:09:58AM -0400, Tom Lane wrote: > >> Thinking about it from the perspective of someone dealing with an > >> installation tree not a source tree, maybe the reference should > >> be to "server/catalog/pg_type_d.h". That might help disabuse > >> anyone who's expecting to find it at that path in the git tree. > > > I am confused what the "server/" prefix means in a path name. > > That is the path underneath the installation "include" directory > at which that file will be found. Uh, I don't see it: $ ls -w 80 /usr/local/pgsql/include/ ecpg_config.hlibpq pgtypes_date.h server ecpgerrno.h libpq-events.h pgtypes_error.h sql3types.h ecpg_informix.h libpq-fe.h pgtypes.hsqlca.h ecpglib.hpg_config_ext.h pgtypes_interval.h sqlda-compat.h ecpgtype.h pg_config.h pgtypes_numeric.hsqlda.h informix pg_config_manual.h pgtypes_timestamp.h sqlda-native.h internal pg_config_os.h postgres_ext.h -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Re: Missing file is mentioned on page https://www.postgresql.org/docs/13/libpq-exec.html
Bruce Momjian writes: > On Tue, Nov 10, 2020 at 06:15:29PM -0500, Tom Lane wrote: >> That is the path underneath the installation "include" directory >> at which that file will be found. > Uh, I don't see it: > $ ls -w 80 /usr/local/pgsql/include/ > ecpg_config.hlibpq pgtypes_date.h server ^^ You didn't do "ls -R", but I have every confidence that it's underneath there. regards, tom lane
Re: Missing file is mentioned on page https://www.postgresql.org/docs/13/libpq-exec.html
On Tue, Nov 10, 2020 at 06:15:29PM -0500, Tom Lane wrote: > Bruce Momjian writes: > > On Fri, Oct 30, 2020 at 11:09:58AM -0400, Tom Lane wrote: > >> Thinking about it from the perspective of someone dealing with an > >> installation tree not a source tree, maybe the reference should > >> be to "server/catalog/pg_type_d.h". That might help disabuse > >> anyone who's expecting to find it at that path in the git tree. > > > I am confused what the "server/" prefix means in a path name. > > That is the path underneath the installation "include" directory > at which that file will be found. Yep, it's there. I thought I checked for an include/catalog install directory, but obviously not well enough. > > We currently say: > > > The OIDs of the built-in data types are defined in > > the file src/include/catalog/pg_type_d.h in the > > source tree. > > Yeah, so also s/source tree/install tree/. OK, here is a patch that mentions both. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index 9ce32fb39b..73c6a6ea4d 100644 --- a/doc/src/sgml/libpq.sgml +++ b/doc/src/sgml/libpq.sgml @@ -3666,8 +3666,8 @@ Oid PQftype(const PGresult *res, You can query the system table pg_type to obtain the names and properties of the various data types. The OIDs of the built-in data types are defined - in the file src/include/catalog/pg_type_d.h - in the source tree. + in the file include/catalog/pg_type_d.h + in the compiled source directory and install directory.
Re: Tips about using mount point directly as the data_directory.
Sorry, this information hides a little bit deep inside the document, I tried my best to find this but missed. David G. Johnston 于2020年11月10日周二 下午10:23写道： > On Tuesday, November 10, 2020, PG Doc comments form < > nore...@postgresql.org> wrote: > >> The following documentation comment has been logged on the website: >> >> Page: https://www.postgresql.org/docs/13/bug-reporting.html >> Description: >> >> Using a mount point directly as the data_directory is not recommended, but >> this tip is not recorded in the doc >> https://www.postgresql.org/docs/11/runtime-config-file-locations.html or >> any >> where else. I suggest adding this tip in the doc when introducing >> configuration option 'data_directory' in >> https://www.postgresql.org/docs/11/runtime-config-file-locations.html. >> > > > A link to the spot in the documentation to where this, and other points, > are discussed would probably be better. > > https://www.postgresql.org/docs/13/creating-cluster.html > > David J. > >
