Re: [DOCS] The reference to 'atacontrol' on FreeBSD is outdated.
On 8/8/17 18:40, [email protected] wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/9.6/static/wal-reliability.html > Description: > > Hi, > > On this page: > https://www.postgresql.org/docs/9.6/static/wal-reliability.html > > ... there is a reference to 'atacontrol' on FreeBSD: 'On FreeBSD, > IDE drives > can be queried using atacontrol...' > > This command was deprecated in FreeBSD 9.0 which was released in January > 2012. Here is a link to the relevant man page highlighting its obsolesence: > https://www.freebsd.org/cgi/man.cgi?query=atacontrol&sektion=8&apropos=0&manpath=FreeBSD+9.0-RELEASE > > The 'camcontrol' is the replacement. Could you supply a new phrasing of that paragraph? Does camcontrol now handle both IDE and SCSI? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] pg_restore -l documentation
On 8/3/17 15:56, Jeff Janes wrote: > The docs for the -l switch in pg_restore say: > > List the contents of the archive. > > this is weird, because everywhere else we use "table of contents" to > describe this, which makes it seem like just plain 'contents' should > mean the bulk table data. > > Attached patch changes it to say: > > List the table of contents of the archive. Committed, thanks! -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] obsolete description for rolreplication in pg_authid and pg_roles
On 3/21/17 15:00, Fujii Masao wrote: > catalog.sgml >> That is, this role can initiate streaming replication (see Section >> 26.2.5, “Streaming Replication”) and set/unset the system backup >> mode using pg_start_backup and pg_stop_backup > > The latter part of the above description for rolreplication column seems > obsolete because commit 1574783b4ced0356fbc626af1a1a469faa6b41e1 > changed pg_start_backup and pg_stop_backup so that GRANT system > is used to manage access to those functions. So I think that we should > get rid of the latter part or replace it with something like "run > pg_basebackup > to take a base backup". Thought? fixed -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Improve docuemntation for cidr/inet
On 4/22/17 04:19, [email protected] wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/9.6/static/datatype-net-types.html > Description: > > >The essential difference between inet and cidr data types is that inet > accepts values with nonzero bits to the right of the netmask, whereas cidr > does not. > > May you please provide example to see the difference visually. I do not > understand that sentence completely I have added an example to the version 10 documentation. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] Contradicting information on the "vacuum threshold"
On the one hand the manual for autovacuum_analyze_threshold claims here: https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-ANALYZE-THRESHOLD > Specifies the minimum number of inserted, updated or deleted tuples needed to trigger an ANALYZE in any one table. Similar in pg_settings.short_desc: > Minimum number of tuple inserts, updates, or deletes prior to analyze. "Minimum" indicates "row_count >= vacuum threshold". (Well "prior" makes that less clear ..) On the other hand the manual explains here: https://www.postgresql.org/docs/current/static/routine-vacuuming.html#AUTOVACUUM > Otherwise, if the number of tuples obsoleted since the last VACUUM exceeds the "vacuum threshold", the table is vacuumed. "Exceeds" indicates "row_count > vacuum threshold". Actual test results seem to support "row_count > vacuum threshold". See test case here: https://dba.stackexchange.com/questions/181960/tiny-table-causes-extreme-performance-degradation-fixed-by-forced-vacuum-why/183283#183283 I suggest to either clarify the manual or change the code to actually use >= instead of > ... and update the explanation for autovacuum accordingly. Same for autovacuum_vacuum_threshold. Regards Erwin Brandstetter
