Re: The suggestion of reducing autovacuum_vacuum_cost_delay should be documented
Thank you all for your fast response. I agree that back patching the default change in general cases should be probably discussed in the hacker mailing list to establish good practice. However, as a user, I would typically just refer to the documentation of the specific version v11 in this case instead of the latest v12. If I follow the v11 doc, I would not be aware of the performance caveat. Since v11 is still a relatively recent release and my testing demonstrates the same significant perf difference exists in v11, I think it might be worth adding the note in the doc or wiki to let the people of older versions know that the default value is changing for catching up modern times. On Wed, May 13, 2020 at 8:17 AM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Tue, May 12, 2020 at 4:59 PM Tom Lane wrote: > >> "David G. Johnston" writes: >> > To be clear, because my cursory reading of the thread that was linked >> from >> > the commit suggested that this specific situation was more "lets catch >> up >> > to modern times", my position isn't that such documentation changes >> should >> > be done as a rule, I am suggesting that we give a yes/no decision on >> this >> > specific change (in advance of bike-shedding the wording). IMO neither >> a >> > blanket rule allowing or prohibiting such a change to the documentation >> > makes sense given the rarity of the event. >> >> Sure. My point was just that changing the back-branch documentation would >> require doing additional testing to verify that the proposed value is >> an improvement in those branches. >> >> > Yeah, details of any testing during v12 didn't make it into the thread, > the main conclusion that did was: > > """ > However, the current settings are predicated on the assumption that > you can't get the kernel to give you a sleep of less than circa 10ms. > That assumption is way outdated, I believe; poking around on systems > I have here, the minimum delay time using pg_usleep(1) seems to be > generally less than 100us, and frequently less than 10us, on anything > released in the last decade. > """ > > Hence assuming this was more of a "modernization". v12 has been out for a > year (yeah, not a super long time, I know) and I'm not recalling any > complaints about the new default. I don't have a feel, though, for what > informal or other measurements that all you hackers do to get a feel for > how safe and useful the change from 20ms to 2ms was. > > David's original post: > > """ > I've had to do quite a bit of performance investigation work this year > and it seems that I only too often discover that the same problem is > repeating itself... > """ > > I'd be inclined to assume many of those investigations were not on v12 > which lends itself to at least wanting to give admins of older versions a > heads-up in the documentation. There seems to be consensus that this is a > win - and people have a couple of months now to demonstrate that it isn't > on older versions. (IOW, I'm not going to prove it one way or another but > everything that went into having this committed in v12 leads me to at least > tell people of older versions we changed things in v12 for reasons - even > if we cover our rear ends and say we simply didn't test older versions and > mileage may vary). > > David J. > > >
Missing comma?
Hello! https://www.postgresql.org/docs/current/catalog-pg-class.html says "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". Am I wrong, or is there a missing comma (or other punctuation mark) before "i = index"?.. -- Marina Polyakova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Re: Missing comma?
> On 13 May 2020, at 12:20, Marina Polyakova wrote: > https://www.postgresql.org/docs/current/catalog-pg-class.html says "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". > Am I wrong, or is there a missing comma (or other punctuation mark) before "i > = index"?.. I agree with this, there should be a comma between "f = all columns" and "i = index with.." per the below: diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index ce33df9e58..cbd76e1bf5 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -1935,7 +1935,7 @@ SCRAM-SHA-256$:&l Columns used to form replica identity for rows: d = default (primary key, if any), n = nothing, - f = all columns + f = all columns, i = index with indisreplident set, or default cheers ./daniel
Re: Missing comma?
Thanks!
P.S. Looking at the final sentence:
"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"
in my opinion it's a little unclear what "or default" means at the end,
because the comma is used to separate enumeration elements ("d = default
<...>, n = nothing, f = all columns, i = index <...>") and inside the
element description ("i = index with indisreplident set, or default").
Therefore here is an additional patch from me to clarify this place,
thanks to Alexander Lakhin for help.
On 2020-05-13 16:23, Daniel Gustafsson wrote:
On 13 May 2020, at 12:20, Marina Polyakova
wrote:
https://www.postgresql.org/docs/current/catalog-pg-class.html says
"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". Am I wrong, or is there a missing
comma (or other punctuation mark) before "i = index"?..
I agree with this, there should be a comma between "f = all columns"
and "i =
index with.." per the below:
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index ce33df9e58..cbd76e1bf5 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -1935,7 +1935,7 @@ SCRAM-SHA-256$:&l
Columns used to form replica identity for rows:
d = default (primary key, if any),
n = nothing,
- f = all columns
+ f = all columns,
i = index with
indisreplident set, or default
cheers ./daniel
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 02ddebae99d98110a8dd290dd4cb0c980adf7984..034a08f80ea4269f131e7e1383ba482fd76d9344 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -1936,7 +1936,7 @@ SCRAM-SHA-256$:&l
d = default (primary key, if any),
n = nothing,
f = all columns,
- i = index with indisreplident set, or default
+ i = index with indisreplident set (if any)
The order of columns about WAL activity in pg_stat_statements
Hi, https://www.postgresql.org/docs/devel/pgstatstatements.html In pg_stat_statements docs, the columns about WAL activity are put in the table in the order of wal_bytes, wal_records and wal_fpi. But in the definition of pg_stat_statements view, wal_bytes is put last. So I think that it's better to reorder those columns in a consistent with the view definition. Patch attached. Thought? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION diff --git a/doc/src/sgml/pgstatstatements.sgml b/doc/src/sgml/pgstatstatements.sgml index b1d5f3d1dc..edacda971f 100644 --- a/doc/src/sgml/pgstatstatements.sgml +++ b/doc/src/sgml/pgstatstatements.sgml @@ -264,15 +264,6 @@ - - wal_bytes - numeric - - -Total amount of WAL bytes generated by the statement - - - wal_records bigint @@ -291,6 +282,15 @@ + + wal_bytes + numeric + + +Total amount of WAL bytes generated by the statement + + +
Re: The order of columns about WAL activity in pg_stat_statements
Fujii Masao writes: > In pg_stat_statements docs, the columns about WAL activity are put > in the table in the order of wal_bytes, wal_records and wal_fpi. But > in the definition of pg_stat_statements view, wal_bytes is put last. > So I think that it's better to reorder those columns in a consistent > with the view definition. Patch attached. Thought? I already fixed this in my pending patch to restructure the catalog docs [1]. regards, tom lane [1] https://www.postgresql.org/message-id/14810.1589128043%40sss.pgh.pa.us
Re: The order of columns about WAL activity in pg_stat_statements
On 2020/05/14 0:41, Tom Lane wrote: Fujii Masao writes: In pg_stat_statements docs, the columns about WAL activity are put in the table in the order of wal_bytes, wal_records and wal_fpi. But in the definition of pg_stat_statements view, wal_bytes is put last. So I think that it's better to reorder those columns in a consistent with the view definition. Patch attached. Thought? I already fixed this in my pending patch to restructure the catalog docs [1]. Sounds nice. Thanks! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
Re: dot dot dot dot
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/tutorial-sql-intro.html Description: is wrong. The four dots are not really a part of the path. Don't use them literally. They indicate that you should use your local path instead. This may differ from installation to installation. Kind regards, Jürgen
TLS docs fixes for
While working with TLS I noticed that the password callback definition had an extra newline in the programlisting in the docs. Since the has been indented with the textblock, the newline comes from whitespace being significant. The attached 0001 fixes by instead anchoring on column zero like how most of the docs do it. Grepping around I found one more instance of the same pattern which is also included. The "Enter PEM pass phrase" prompt was referred to in one place with and one with , the 0002 settles on using for both since IMO that makes the docs more readable. While there, it also fixes the spelling of "pass phrase" from the two variations we had (of which none was the correct one from src/backend/libpq/be-secure-openssl.c as well as the OpenSSL file crypto/pem/pem_lib.c). cheers ./daniel 0002-doc-fix-PEM-prompt-markup.patch Description: Binary data 0001-doc-anchor-programlisting-on-column-zero.patch Description: Binary data
Re: Missing comma?
On Wed, May 13, 2020 at 05:17:43PM +0300, Marina Polyakova wrote:
> in my opinion it's a little unclear what "or default" means at the end,
> because the comma is used to separate enumeration elements ("d = default
> <...>, n = nothing, f = all columns, i = index <...>") and inside the
> element description ("i = index with indisreplident set, or default").
> Therefore here is an additional patch from me to clarify this place, thanks
> to Alexander Lakhin for help.
Yes, I agree that this last "or default" in the docs does not make
much sense, because we always enforce REPLICA_IDENTITY_NOTHING if
there is no replica identity.
> diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
> index
> 02ddebae99d98110a8dd290dd4cb0c980adf7984..034a08f80ea4269f131e7e1383ba482fd76d9344
> 100644
> --- a/doc/src/sgml/catalogs.sgml
> +++ b/doc/src/sgml/catalogs.sgml
> @@ -1936,7 +1936,7 @@ SCRAM-SHA-256$ count>:&l
> d = default (primary key, if any),
> n = nothing,
> f = all columns,
> - i = index with
> indisreplident set, or default
> + i = index with
> indisreplident set (if any)
>
>
And you don't need the ("if any") either here, no?
REPLICA_IDENTITY_INDEX means that we have an index associated with the
replica identity so it seems to me that this last part can just be
removed.
--
Michael
signature.asc
Description: PGP signature
Re: TLS docs fixes for
On Wed, May 13, 2020 at 11:07:44PM +0200, Daniel Gustafsson wrote: > While working with TLS I noticed that the password callback definition had an > extra newline in the programlisting in the docs. Since the > has been indented with the textblock, the newline comes from whitespace being > significant. The attached 0001 fixes by instead anchoring on > column zero like how most of the docs do it. Grepping around I found one more > instance of the same pattern which is also included. Indeed, I can see the difference. In what I spotted after applying 0001, you are patching the one in libpq.sgml as of 0002 but in a different, correct, way, and I have spotted three more inconsistencies within doc/src/sgml/datatype.sgml in the zone for timestamps. > The "Enter PEM pass phrase" prompt was referred to in one place with > and one with , the 0002 settles on using for both > since IMO that makes the docs more readable. While there, it also fixes the > spelling of "pass phrase" from the two variations we had (of which none was > the > correct one from src/backend/libpq/be-secure-openssl.c as well as the OpenSSL > file crypto/pem/pem_lib.c). Yeah, good catch. Let's fix that. With everything I found on top of your stuff, I finish with the attached. Does it look fine to you? -- Michael diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml index a8d0780387..86eb38cc8f 100644 --- a/doc/src/sgml/datatype.sgml +++ b/doc/src/sgml/datatype.sgml @@ -2095,11 +2095,15 @@ January 8 04:05:06 1999 PST + or - symbol and time zone offset after the time. Hence, according to the standard, - TIMESTAMP '2004-10-19 10:23:54' + +TIMESTAMP '2004-10-19 10:23:54' + is a timestamp without time zone, while - TIMESTAMP '2004-10-19 10:23:54+02' + +TIMESTAMP '2004-10-19 10:23:54+02' + is a timestamp with time zone. PostgreSQL never examines the content of a @@ -2108,7 +2112,9 @@ January 8 04:05:06 1999 PST ensure that a literal is treated as timestamp with time zone, give it the correct explicit type: - TIMESTAMP WITH TIME ZONE '2004-10-19 10:23:54+02' + +TIMESTAMP WITH TIME ZONE '2004-10-19 10:23:54+02' + In a literal that has been determined to be timestamp without time zone, PostgreSQL will silently ignore diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index 5892367c61..75c7c5837b 100644 --- a/doc/src/sgml/libpq.sgml +++ b/doc/src/sgml/libpq.sgml @@ -790,9 +790,9 @@ void PQsetSSLKeyPassHook(PQsslKeyPassHook_type hook); The application passes a pointer to a callback function with signature: - - int callback_fn(char *buf, int size, PGconn *conn); - + +int callback_fn(char *buf, int size, PGconn *conn); + which libpq will then call instead of its default PQdefaultSSLKeyPassHook handler. The callback should determine the password for the key and copy it to result-buffer @@ -1668,7 +1668,7 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname Specifying this parameter with any non-empty value suppresses the -Enter PEM passphrase: +Enter PEM pass phrase: prompt that OpenSSL will emit by default when an encrypted client certificate key is provided to libpq. @@ -7667,10 +7667,7 @@ ldap://ldap.acme.com/cn=dbserver,cn=hosts?pgconnectinfo?base?(objectclass=*) may be provided in the connection option. If an encrypted key is supplied and the sslpassword option is absent or blank, a password will be prompted for interactively by - OpenSSL with a - -Enter PEM Passphrase: - + OpenSSL with a Enter PEM pass phrase: prompt if a TTY is available. Applications can override the client certificate prompt and the handling of the sslpassword parameter by supplying their own key password callback; see . diff --git a/doc/src/sgml/postgres-fdw.sgml b/doc/src/sgml/postgres-fdw.sgml index 94992be427..eab2cc9378 100644 --- a/doc/src/sgml/postgres-fdw.sgml +++ b/doc/src/sgml/postgres-fdw.sgml @@ -151,10 +151,10 @@ A superuser may override this check on a per-user-mapping basis by setting the user mapping option password_required 'false', e.g. - - ALTER USER MAPPING FOR some_non_superuser SERVER loopback_nopw - OPTIONS (ADD password_required 'false'); - + +ALTER USER MAPPING FOR some_non_superuser SERVER loopback_nopw +OPTIONS (ADD password_required 'false'); + To prevent unprivileged users from exploiting the authentication rights of the unix user the postgres server is running as to escalate to superuser rights, only the superuser may set this option on a user mapping. signature.asc Description: PGP signature
Re: Another modest proposal for docs formatting: catalog descriptions
On 5/10/20 2:03 PM, Jonathan S. Katz wrote: > On 5/10/20 12:27 PM, Tom Lane wrote: >> Just FTR, here's a complete patch for this. > > Cool. I'll play around with it tonight once I clear out release work. > Per upthread reference, I believe you've become a CSS maven yourself. Time slipped a bit (sorry!), but while prepping for the release I reviewed this. Visually, it looks WAY better. The code checks out too. I think any tweaks would be primarily around personal preference on the UI, so it may be better just to commit and get it out in the wild. ...and so I did. Committed[1]. Jonathan [1] https://git.postgresql.org/gitweb/?p=pgweb.git;a=commitdiff;h=93716f2a817dbdae8cccf86bc951b45b68ea52d9 signature.asc Description: OpenPGP digital signature
Re: Another modest proposal for docs formatting: catalog descriptions
"Jonathan S. Katz" writes: > Time slipped a bit (sorry!), but while prepping for the release I > reviewed this. Visually, it looks WAY better. The code checks out too. I > think any tweaks would be primarily around personal preference on the > UI, so it may be better just to commit and get it out in the wild. > ...and so I did. Committed[1]. Thanks, I'll push the docs change in a bit. regards, tom lane
