Re: Small mistake (grammar/wording)
On Tue, Apr 2, 2019 at 08:39:39AM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/11/libpq-exec.html > Description: > > Hi, > > just found a small mistake in > https://www.postgresql.org/docs/current/libpq-exec.html (Version 11 Chapter > 34.3), the sentence that starts with "Note that it is not necessary nor > correct to do escaping..." should be changed to "Note that it is neither > necessary nor correct to do escaping...". Fixed in all supported branches. Thanks. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: REFRESH MATERIALIZED VIEW CONCURRENTLY interaction with ORDER BY
On Thu, Apr 4, 2019 at 02:54:29PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/sql-refreshmaterializedview.html > Description: > > On 10.7 we hit a case where the backing query had an order by clause and a > concurrent refresh updated it differently than a normal refresh. This is a > bit of an odd corner case given that up till that point, views would respect > the ordering. > > It's not explicit that CONCURRENTLY populates the data any differently than > normal, specifically, in a way that means the ordering in the backing query > is not always maintained, depending on the order of updates. > > Reading through the comment at > https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/commands/matview.c;h=2aac63296bfee535af3ea660c617b265d7ec8042;hb=HEAD#l548 > I can see the logic in that, but it could use an explicit mention in the > CONCURRENTLY section. Not sure if there's any plan for changing the > behaviour either. > > Also the existing sentence "If you want the data to be ordered upon > generation, you must use an ORDER BY clause in the backing query." sort of > implies that the ORDER BY will be respected. I ran the attached SQL file on PG 10.7 and PG head and got output that honored the ORDER BY. Is the test wrong? Is something else needed to see the ordering fail. Can you provide an example of the failure? If I remove the ORDER BY from the materialized view, I do get randomly ordered rows. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + materialized.sql Description: application/sql
Re: Clarification to pg_upgrade docs on reverting to old cluster
On Fri, Apr 5, 2019 at 02:23:22PM +, Daniel Gustafsson wrote: > On Friday, April 5, 2019 2:26 PM, Magnus Hagander wrote: > but wouldn't it sound better with "in this case" than "at this point"? And > as a really small nitpick, restore from backup, rather than backups? > > > Agreed. > > > The third bulletpoint also seems quite complicated really. If we're > tweaking these, wouldn't it be better if we split that one in two -- one > for "if you ran it without --link", that should reallyi be listed above > any > of the other options? > > > Looking at it closer I tend to agree, and updated the patch to split this up > in > an attempt to make it a bit clearer for newcomers to pg_upgrade. How about the > attached version? I agree that current paragraph is terrible --- it is too dense and confusing. I liked your sub-bullets. I adjusted your patch to tighten the language, and reordered the entries to appear in the order the actions would be performed. Updated patch attached. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml index f6d423ee13..0c4b16d32c 100644 --- a/doc/src/sgml/ref/pgupgrade.sgml +++ b/doc/src/sgml/ref/pgupgrade.sgml @@ -678,32 +678,52 @@ psql --username=postgres --file=script.sql postgres -If you ran pg_upgrade -with --check, no modifications were made to the old -cluster and you can re-use it anytime. +If the --check option was used, the old cluster +was unmodified; it can be restarted. -If you ran pg_upgrade -with --link, the data files are shared between the -old and new cluster. If you started the new cluster, the new -server has written to those shared files and it is unsafe to -use the old cluster. +If the --link option was not +used, the old cluster was unmodified; it can be restarted. -If you ran pg_upgrade without ---link or did not start the new server, the -old cluster was not modified except that, if linking -started, a .old suffix was appended to -$PGDATA/global/pg_control. To reuse the old -cluster, possibly remove the .old suffix from -$PGDATA/global/pg_control; you can then restart the -old cluster. +If the --link option was used, the data +files might be shared between the old and new cluster: + + + + + If pg_upgrade aborted before linking started, + the old cluster was unmodified; it can be restarted. + + + + + + If you did not start the new cluster, the old + cluster was unmodified except that, when linking started, a + .old suffix was appended to + $PGDATA/global/pg_control. To reuse the old + cluster, remove the .old suffix from + $PGDATA/global/pg_control; you can then restart + the old cluster. + + + + + + If you did start the new cluster, it has written to shared files + and it is unsafe to use the old cluster. The old cluster will + need to be restored from backup in this case. + + + +
Re: Mark a reloption as indexterm
On Wed, Apr 10, 2019 at 4:11 AM Alvaro Herrera wrote: > > On 2019-Apr-10, Fujii Masao wrote: > > > Hi, > > > > I'd like to propose to mark reloptions as indexterms, like GUC, > > so that users can more easily search the pages describing > > a reloption in document. Attached is the patch which does this. > > Is this helpful? Thought? > > +1 for adding index entries to all reloptions. I'm not sure what you're > achieving by splitting the text for some existing index entries in two > and putting two words in the that were part of the > , though. I'd just put the whole text in (obviously > the option name must be the first word of that). Indeed. Attached is the updated version of the patch. Regards, -- Fujii Masao reloption-doc-v2.patch Description: Binary data
Re: Mark a reloption as indexterm
On Fri, Apr 12, 2019 at 12:33:45PM +0900, Fujii Masao wrote: > Indeed. Attached is the updated version of the patch. On top of what Alvaro has mentioned, it seems to me that we should make the difference between table-level configuration parameter and index-level configuration parameters, and also add markups to create_index.sgml. If you take the example of fillfactor, it applies to both indexes and tables, but with your patch you just define "configuration parameter", and point to only CREATE TABLE. -- Michael signature.asc Description: PGP signature
Re: Mark a reloption as indexterm
On 2019-Apr-12, Fujii Masao wrote: > On Wed, Apr 10, 2019 at 4:11 AM Alvaro Herrera > wrote: > > > > On 2019-Apr-10, Fujii Masao wrote: > > > > > Hi, > > > > > > I'd like to propose to mark reloptions as indexterms, like GUC, > > > so that users can more easily search the pages describing > > > a reloption in document. Attached is the patch which does this. > > > Is this helpful? Thought? > > > > +1 for adding index entries to all reloptions. I'm not sure what you're > > achieving by splitting the text for some existing index entries in two > > and putting two words in the that were part of the > > , though. I'd just put the whole text in (obviously > > the option name must be the first word of that). > > Indeed. Attached is the updated version of the patch. Hmm, actually, I now see you were originally proposing the words "storage parameter" for the fillfactor index entries, but for v2 you instead copied the "configuration parameter" words that was in some other of the older entries. I think "configuration parameter" is wrong (we use that for GUCs, and it seems to me that it would be confusing to mix both things), and we should use the words "storage parameter" for all of these, don't you think? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Mark a reloption as indexterm
On 2019-Apr-12, Michael Paquier wrote: > On Fri, Apr 12, 2019 at 12:33:45PM +0900, Fujii Masao wrote: > > Indeed. Attached is the updated version of the patch. > > On top of what Alvaro has mentioned, it seems to me that we should > make the difference between table-level configuration parameter and > index-level configuration parameters, and also add markups > to create_index.sgml. If you take the example of fillfactor, it > applies to both indexes and tables, but with your patch you just > define "configuration parameter", and point to only CREATE TABLE. Are you suggesting that it should show "index storage parameters" and "table storage parameters"? I'm not sure about that myself ... particularly considering that certain parameters might apply to some index AMs and not others. BTW what about the index-specific options such as, say, BRIN's pages_per_range? I know other AMs have their own reloptions ... -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Mark a reloption as indexterm
On Thu, Apr 11, 2019 at 11:57:32PM -0400, Alvaro Herrera wrote: > Are you suggesting that it should show "index storage parameters" and > "table storage parameters"? I'm not sure about that myself ... > particularly considering that certain parameters might apply to some > index AMs and not others. Yes, that's exactly what I was suggesting: putting all the index-related parameters into an index bucket, without caring about the AM involved. -- Michael signature.asc Description: PGP signature
Re: Mark a reloption as indexterm
On Fri, Apr 12, 2019 at 12:54 PM Alvaro Herrera wrote: > > On 2019-Apr-12, Fujii Masao wrote: > > > On Wed, Apr 10, 2019 at 4:11 AM Alvaro Herrera > > wrote: > > > > > > On 2019-Apr-10, Fujii Masao wrote: > > > > > > > Hi, > > > > > > > > I'd like to propose to mark reloptions as indexterms, like GUC, > > > > so that users can more easily search the pages describing > > > > a reloption in document. Attached is the patch which does this. > > > > Is this helpful? Thought? > > > > > > +1 for adding index entries to all reloptions. I'm not sure what you're > > > achieving by splitting the text for some existing index entries in two > > > and putting two words in the that were part of the > > > , though. I'd just put the whole text in (obviously > > > the option name must be the first word of that). > > > > Indeed. Attached is the updated version of the patch. > > Hmm, actually, I now see you were originally proposing the words > "storage parameter" for the fillfactor index entries, but for v2 you > instead copied the "configuration parameter" words that was in some > other of the older entries. I think "configuration parameter" is wrong > (we use that for GUCs, and it seems to me that it would be confusing to > mix both things), and we should use the words "storage parameter" for > all of these, don't you think? So you are suggesting to use xxx storage parameter for reltoption and xxx configuration parameter for GUC? If we do that, the following two lines are in the index. xxx configuration parameter, XXX xxx storage parameter, Storage Parameter OTOH, originally I thought that the following style is smarter. xxx configuration parameter, XXX storage parameter, Storage Parameter Regards, -- Fujii Masao
Re: Mark a reloption as indexterm
On Fri, Apr 12, 2019 at 1:09 PM Michael Paquier wrote: > > On Thu, Apr 11, 2019 at 11:57:32PM -0400, Alvaro Herrera wrote: > > Are you suggesting that it should show "index storage parameters" and > > "table storage parameters"? I'm not sure about that myself ... > > particularly considering that certain parameters might apply to some > > index AMs and not others. > > Yes, that's exactly what I was suggesting: putting all the > index-related parameters into an index bucket, without caring about > the AM involved. +1 While reading the doc for index reloptins, I found that there is no information about the type for each index reloption in the doc. Probably it's worth adding that information, like the doc for table reloptions have. Regards, -- Fujii Masao
Re: Clarification to pg_upgrade docs on reverting to old cluster
On Friday, April 12, 2019 3:48 AM, Bruce Momjian wrote: > On Fri, Apr 5, 2019 at 02:23:22PM +, Daniel Gustafsson wrote: > > > On Friday, April 5, 2019 2:26 PM, Magnus Hagander mag...@hagander.net wrote: > > but wouldn't it sound better with "in this case" than "at this point"? And > > as a really small nitpick, restore from backup, rather than backups? > > Agreed. > > > > The third bulletpoint also seems quite complicated really. If we're > > tweaking these, wouldn't it be better if we split that one in two -- one > > for "if you ran it without --link", that should reallyi be listed above > > any > > of the other options? > > > > > > Looking at it closer I tend to agree, and updated the patch to split this > > up in > > an attempt to make it a bit clearer for newcomers to pg_upgrade. How about > > the > > attached version? > > I agree that current paragraph is terrible --- it is too dense and > confusing. I liked your sub-bullets. I adjusted your patch to tighten > the language, and reordered the entries to appear in the order the > actions would be performed. > > Updated patch attached. The order of the bullets is much better in your patch, thanks! cheers ./daniel
