Re: [DOCS] PATCH: Warn users about tablespace abuse data loss risk
On Thu, Feb 13, 2014 at 08:15:59AM +0800, Craig Ringer wrote: > On 02/12/2014 02:35 PM, Ian Lawrence Barwick wrote: > > And taking a look at the page in question I see this prominent example: > > > > CREATE TABLESPACE fastspace LOCATION '/mnt/sda1/postgresql/data'; > > Here's an updated patch, adopting your wording for the first par and > tweaking the example. I have applied an adjusted version of this patch that is more compact. Thanks. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + diff --git a/doc/src/sgml/manage-ag.sgml b/doc/src/sgml/manage-ag.sgml new file mode 100644 index b44d521..78ec509 *** a/doc/src/sgml/manage-ag.sgml --- b/doc/src/sgml/manage-ag.sgml *** dropdb db *** 379,395 expensive, slower disk system. To define a tablespace, use the command, for example:CREATE TABLESPACE: ! CREATE TABLESPACE fastspace LOCATION '/mnt/sda1/postgresql/data'; The location must be an existing, empty directory that is owned by the PostgreSQL operating system user. All objects subsequently created within the tablespace will be stored in files underneath this !directory. --- 379,412 expensive, slower disk system. + + + Even though located outside the main PostgreSQL data directory, + tablespaces are an integral part of the database cluster and + cannot be treated as an autonomous collection + of data files. They are dependent on metadata contained in the main + data directory, and therefore cannot be attached to a different + database cluster or backed up individually. Similarly, if you lose + a tablespace (file deletion, disk failure, etc), the database cluster + might become unreadable or unable to start. Placing a tablespace + on a temporary file system like a ramdisk risks the reliability of + the entire cluster. + + + To define a tablespace, use the command, for example:CREATE TABLESPACE: ! CREATE TABLESPACE fastspace LOCATION '/ssd1/postgresql/data'; The location must be an existing, empty directory that is owned by the PostgreSQL operating system user. All objects subsequently created within the tablespace will be stored in files underneath this !directory. The location must not be on removable or transient storage, !as the cluster might fail to function if the tablespace is missing !or lost. diff --git a/doc/src/sgml/ref/create_tablespace.sgml b/doc/src/sgml/ref/create_tablespace.sgml new file mode 100644 index b643565..cf6215e *** a/doc/src/sgml/ref/create_tablespace.sgml --- b/doc/src/sgml/ref/create_tablespace.sgml *** CREATE TABLESPACE . + + + -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Docs incorrectly claiming equivalence between show and pg_settings
On Wed, Feb 12, 2014 at 03:54:31PM +0100, Stefan Seifert wrote: > Hi! > > http://www.postgresql.org/docs/devel/static/sql-show.html claims: > "Also, the pg_settings system view produces the same information." > > This is not entirely correct. On IRC I was told, that the view only contains > settings set from C, not user defined settings defined by the SET command: > > timemngt=# set my.test = 'test'; > > > SET > > > timemngt=# show my.test; > > > ┌─┐ > > > │ my.test │ > > > ├─┤ > > > │ test│ > > > └─┘ > > > (1 row) > > > > timemngt=# select * from pg_settings where name = 'my.test'; > > > timemngt=# > > Including this rather obscure bit of information might help another user down > the road. This is an interesting report. You are correct that there are several places in the docs that say that SHOW and pg_settings display the same information, and even state that pg_settings shows _more_ information than SHOW. However, in the case of custom variables, you are right that pg_settings doesn't show custom variables. I have found the place in the code where we do that using GUC_NO_SHOW_ALL. I believe the original reason for this is that custom variables were designed to modify plugin languages and therefore not useful for people doing SHOW ALL, but if you specifically asked for it, it would show it to you. Because pg_settings is built as a view, the API doesn't really have an ALL mode. We can do a few things: 1 show custom variables in SHOW ALL and pg_settings 2 show custom and other non-SHOW-ALL variables in pg_settings 3 document this restriction I am not sure which approach is best. I am attaching a patch that does #1. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c new file mode 100644 index 15020c4..c0f9880 *** a/src/backend/utils/misc/guc.c --- b/src/backend/utils/misc/guc.c *** add_placeholder_variable(const char *nam *** 3929,3936 gen->context = PGC_USERSET; gen->group = CUSTOM_OPTIONS; ! gen->short_desc = "GUC placeholder variable"; ! gen->flags = GUC_NO_SHOW_ALL | GUC_NOT_IN_SAMPLE | GUC_CUSTOM_PLACEHOLDER; gen->vartype = PGC_STRING; /* --- 3929,3936 gen->context = PGC_USERSET; gen->group = CUSTOM_OPTIONS; ! gen->short_desc = "Custom variable."; ! gen->flags = GUC_NOT_IN_SAMPLE | GUC_CUSTOM_PLACEHOLDER; gen->vartype = PGC_STRING; /* -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] archive_command vs recovery_command paths
On Thu, Feb 13, 2014 at 08:20:02AM +0800, Craig Ringer wrote: > Hi folks > > Another point of confusion I've been seeing a lot in users on Stack > Overflow, dba.stackexchange.com, etc surrounds the meaning of paths > given in archive_command and restore_command. > > Lots of people seem to assume that they are both relative to the master, > and that the master will run the restore_command to fetch archives to > send to the replica on request. > > (Yes, I know that's completely missing the point of archive-based > replication, but it seems common). > > So I think docs changes are needed to the explanations of those options, > and to the replication/recovery section, that better explain that we > assume there's shared storage like NFS involved, and if there isn't you > need to use commands like scp/rsync instead, or use tools like WAL-E. > > I'm not going to get time to do this one for at least a few days, but > I'm posting it now partly so I don't forget about it. I have applied the attached patch which at least clarifies this issue. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml new file mode 100644 index 17ef25b..4a33f87 *** a/doc/src/sgml/config.sgml --- b/doc/src/sgml/config.sgml *** include 'filename' *** 2279,2285 ! The shell command to execute to archive a completed WAL file segment. Any %p in the string is replaced by the path name of the file to archive, and any %f is replaced by only the file name. --- 2279,2285 ! The local shell command to execute to archive a completed WAL file segment. Any %p in the string is replaced by the path name of the file to archive, and any %f is replaced by only the file name. diff --git a/doc/src/sgml/recovery-config.sgml b/doc/src/sgml/recovery-config.sgml new file mode 100644 index 9335aca..c9ed2df *** a/doc/src/sgml/recovery-config.sgml --- b/doc/src/sgml/recovery-config.sgml *** *** 42,48 ! The shell command to execute to retrieve an archived segment of the WAL file series. This parameter is required for archive recovery, but optional for streaming replication. Any %f in the string is --- 42,48 ! The local shell command to execute to retrieve an archived segment of the WAL file series. This parameter is required for archive recovery, but optional for streaming replication. Any %f in the string is -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
