From b645a05fc6112a4857ceac574d4aa24174a70417 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Sat, 17 Dec 2016 12:00:00 -0500 Subject: [PATCH] doc: Remove some trailing whitespace Per discussion, we will not at this time remove trailing whitespace in psql output displays where it is part of the actual psql output. From: Vladimir Rusinov --- doc/src/sgml/config.sgml | 2 +- doc/src/sgml/parallel.sgml | 22 +++++++++++----------- doc/src/sgml/ref/alter_table.sgml | 2 +- doc/src/sgml/ref/insert.sgml | 2 +- doc/src/sgml/ref/prepare.sgml | 2 +- doc/src/sgml/ref/reindexdb.sgml | 2 +- 6 files changed, 16 insertions(+), 16 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 0fc4e57d900..3b614b6ecdf 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -1181,7 +1181,7 @@ include_dir 'conf.d' it in plaintext. on and off are also accepted, as aliases for md5 and plain, respectively. - + diff --git a/doc/src/sgml/parallel.sgml b/doc/src/sgml/parallel.sgml index cf4c1c9c2a9..bca4886b21e 100644 --- a/doc/src/sgml/parallel.sgml +++ b/doc/src/sgml/parallel.sgml @@ -134,12 +134,12 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%'; - + The query writes any data or locks any database rows. If a query contains a data-modifying operation either at the top level or within a CTE, no parallel plans for that query will be generated. This is a limitation of the current implementation which could be lifted in a - future release. + future release. @@ -153,7 +153,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%'; FOR x IN query LOOP .. END LOOP will never use a parallel plan, because the parallel query system is unable to verify that the code in the loop is safe to execute while parallel query is - active. + active. @@ -174,7 +174,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%'; query itself, that query will never use a parallel plan. This is a limitation of the current implementation, but it may not be desirable to remove this limitation, since it could result in a single query - using a very large number of processes. + using a very large number of processes. @@ -197,7 +197,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%'; - + No background workers can be obtained because of the limitation that the total number of background workers cannot exceed . @@ -205,7 +205,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%'; - + No background workers can be obtained because of the limitation that the total number of background workers launched for purposes of parallel query cannot exceed . @@ -213,7 +213,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%'; - + The client sends an Execute message with a non-zero fetch count. See the discussion of the extended query protocol. @@ -228,7 +228,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%'; - + A prepared statement is executed using a CREATE TABLE .. AS EXECUTE .. statement. This construct converts what otherwise would have been a read-only operation into a read-write operation, @@ -237,7 +237,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%'; - + The transaction isolation level is serializable. This situation does not normally arise, because parallel query plans are not generated when the transaction isolation level is serializable. @@ -467,7 +467,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%'; transaction. If you write a function which does this, and this behavior difference is important to you, mark such functions as PARALLEL RESTRICTED - to ensure that they execute only in the leader. + to ensure that they execute only in the leader. @@ -475,7 +475,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%'; parallel-restricted functions or aggregates involved in the query in order to obtain a superior plan. So, for example, if a WHERE clause applied to a particular table is parallel restricted, the query - planner will not consider placing the scan of that table below a + planner will not consider placing the scan of that table below a Gather node. In some cases, it would be possible (and perhaps even efficient) to include the scan of that table in the parallel portion of the query and defer the evaluation of the diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml index 333b01db36e..8ea66241470 100644 --- a/doc/src/sgml/ref/alter_table.sgml +++ b/doc/src/sgml/ref/alter_table.sgml @@ -1121,7 +1121,7 @@ ALTER TABLE [ IF EXISTS ] name Also, because selecting from the parent also selects from its descendents, a constraint on the parent cannot be marked valid unless it is also marked valid for those descendents. In all of these cases, ALTER TABLE - ONLY will be rejected. + ONLY will be rejected. diff --git a/doc/src/sgml/ref/insert.sgml b/doc/src/sgml/ref/insert.sgml index 00c984d8d54..9339826818c 100644 --- a/doc/src/sgml/ref/insert.sgml +++ b/doc/src/sgml/ref/insert.sgml @@ -526,7 +526,7 @@ INSERT oid count - + Notes diff --git a/doc/src/sgml/ref/prepare.sgml b/doc/src/sgml/ref/prepare.sgml index 8efd51aaec9..fea2196efee 100644 --- a/doc/src/sgml/ref/prepare.sgml +++ b/doc/src/sgml/ref/prepare.sgml @@ -73,7 +73,7 @@ PREPARE name [ ( reindexdb connection-option option - + -- 2.39.5