Re: Missing comma?
On 2020-05-19 05:49, Michael Paquier wrote: On Mon, May 18, 2020 at 10:31:35PM +0300, Marina Polyakova wrote: On 2020-05-18 09:16, Michael Paquier wrote: Would you like to send an updated patch? Note that as the release of beta1 is planned for this week, we have a grace period until the version is tagged on HEAD. The patch is attached, changes to html such as they were discussed. Looks good to me. Thanks! Here is a patch with a fixed commit message (primary index => primary key). -- Marina Polyakova Postgres Professional: http://www.postgrespro.com The Russian Postgres CompanyFrom 2a54810f4e0c1a456d906d209268559af476c937 Mon Sep 17 00:00:00 2001 From: Marina Polyakova Date: Mon, 18 May 2020 22:19:46 +0300 Subject: [PATCH v2] Fix the description of the field pg_class.relreplident - Add a comma between "f = all columns" and "i = index with ...". - Fix the description of replica identity index if the index used got dropped (in this case we cannot update or delete rows from the table if the action is published even if the table has a primary key). --- doc/src/sgml/catalogs.sgml | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index b1b077c97f..58a25e8e68 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2141,8 +2141,10 @@ SCRAM-SHA-256$:&l Columns used to form replica identity for rows: d = default (primary key, if any), n = nothing, - f = all columns - i = index with indisreplident set, or default + f = all columns, + i = index with + indisreplident set (same as nothing if the + index used got dropped) -- 2.17.1
11.7 Indexes on Expressions: editorial correction
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/indexes-expressional.html Description: The paragraph that begins "If we were to declare this index UNIQUE,..." refers to the index test1_lower_col1_idx, not to the test1_uniq_int index it currently follows. It would appear the latter example was spliced into the middle of discussing the former. The paragraphs should be ordered: CREATE INDEX test1_lower_col1_idx If we were to declare this index UNIQUE, ... Expression indexes also allow control CREATE UNIQUE INDEX test1_uniq_int ...
Re: Add A Glossary
On 2020-05-19 08:17, Laurenz Albe wrote: The term "cluster" is unfortunate, because to most people it suggests a group of machines, so the term "instance" is better, but that ship has sailed long ago. I don't see what would stop us from renaming some things, with some care. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
[PATCH] Clarification of use logical operators inside phrase operator
Hi, all! I noticed that in fulltext search use of logical operator inside phrase operator can be clarified a bit. Of course it's better to provide example from german language, but probably it will not be clear for everyone. So I added english one. Hope it will make the case little bit clearer. Best regards, Pavel Borisov. phrase_search_documentation_patch.diff Description: Binary data
Re: 11.7 Indexes on Expressions: editorial correction
PG Doc comments form writes: > The paragraph that begins "If we were to declare this index UNIQUE,..." > refers to the index test1_lower_col1_idx, not to the test1_uniq_int index it > currently follows. It would appear the latter example was spliced into the > middle of discussing the former. Yes, this was complained of before: https://www.postgresql.org/message-id/flat/E1ikvbp-0005jW-E9%40gemulon.postgresql.org I remain of the opinion that we'd be best off to just revert a9760d0f3 altogether. Bruce's last proposal mostly did that, but it still insisted on muddying an existing example with an unrelated comment. regards, tom lane
descriptions of pg_stat_user_functions and pg_stat_slru
Hi, In monitoring.sgml, there are the tables and corresponding descriptions for pg_stat_user_functions and pg_stat_slru views. I found that those descriptions are located in opposite places. For example, the description for pg_stat_user_functions wrongly comes just after the table for pg_stat_slru view. Attached patch fixes this issue. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml index acc6e2bc31..4810c4a0f1 100644 --- a/doc/src/sgml/monitoring.sgml +++ b/doc/src/sgml/monitoring.sgml @@ -4249,16 +4249,11 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i - - SLRU - - - PostgreSQL accesses certain on-disk information - via SLRU (simple least-recently-used) caches. - The pg_stat_slru view will contain - one row for each tracked SLRU cache, showing statistics about access - to cached pages. + The pg_stat_user_functions view will contain + one row for each tracked function, showing statistics about executions of + that function. The parameter + controls exactly which functions are tracked. @@ -4362,11 +4357,16 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i + + SLRU + + - The pg_stat_user_functions view will contain - one row for each tracked function, showing statistics about executions of - that function. The parameter - controls exactly which functions are tracked. + PostgreSQL accesses certain on-disk information + via SLRU (simple least-recently-used) caches. + The pg_stat_slru view will contain + one row for each tracked SLRU cache, showing statistics about access + to cached pages.
Re: descriptions of pg_stat_user_functions and pg_stat_slru
Fujii Masao writes: > In monitoring.sgml, there are the tables and corresponding descriptions > for pg_stat_user_functions and pg_stat_slru views. I found that those > descriptions are located in opposite places. For example, the description > for pg_stat_user_functions wrongly comes just after the table for > pg_stat_slru view. Attached patch fixes this issue. Hm, I see your point, but I think there is a bigger problem here: this entire section was written with great disregard for our normal conventions of how to lay out text around tables. The standard thing, as seen in Chapter 9 or the system catalog section, is that first you have an introductory paragraph --- preferably containing an actual link to the table --- then you have the table, and then if you feel a need for any footnote-like comments on the table, you put those below it. I seem to recall Peter E. explaining that this is important because some presentations might put the table out-of-line entirely, so you should have an to it. What we've mostly got in 27.2 as it stands is that the explanations are below the tables, which is just backwards. I think the discrepancy you spotted is because I added some text about the pg_stat_slru view and just automatically added it above the table, not noticing that that wasn't what the surrounding stuff did. regards, tom lane
Re: Missing comma?
On Tue, May 19, 2020 at 11:14:56AM +0300, Marina Polyakova wrote: > Here is a patch with a fixed commit message (primary index => primary key). Thanks, applied. -- Michael signature.asc Description: PGP signature
Re: descriptions of pg_stat_user_functions and pg_stat_slru
On 2020/05/20 11:05, Tom Lane wrote: Fujii Masao writes: In monitoring.sgml, there are the tables and corresponding descriptions for pg_stat_user_functions and pg_stat_slru views. I found that those descriptions are located in opposite places. For example, the description for pg_stat_user_functions wrongly comes just after the table for pg_stat_slru view. Attached patch fixes this issue. Hm, I see your point, but I think there is a bigger problem here: this entire section was written with great disregard for our normal conventions of how to lay out text around tables. The standard thing, as seen in Chapter 9 or the system catalog section, is that first you have an introductory paragraph --- preferably containing an actual link to the table --- then you have the table, and then if you feel a need for any footnote-like comments on the table, you put those below it. Yeah, I agree to change the layout that way. Also I don't like that all the stats views are packed in one section currently. Which makes the docs difficult to read, I'm afraid. Thought? If we change the layout entirely, at the same time, what about separating each view into different section by adding ? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
