Re: Installation instructions vs binaries

[Daniel Gustafsson]

> On 15 Sep 2020, at 02:43, David G. Johnston  
> wrote:
> On Tue, Sep 8, 2020 at 8:05 AM Magnus Hagander  > wrote:

> That leaves just the part of adding the actual new chapter of my patch. PFA. 
> Thoughts on that? 

+1 on this version of the patch.

It seems a bit odd to me to capitalize Download, but since it's the name of the
referenced section I guess it's ok. Personally I'd have lowercased it.
+  the Download section on the PostgreSQL website at

> I kinda want to be blunt, though, and point out that if the user is using a 
> pre-packaged version that the packager, and not the core team, accepts 
> responsibility for problem reports related to installation, on their support 
> channel.  Please don't use pg-bugs.

I don't think it's reasonable to expect users to be able to separate bugs
caused by the installer and supporting scripts/wrappers, and those by for
example initdb.  AFAICR it's mostly the Windows installer which we get reports
for on -bugs, and the devs responsible for said installer have been quite quick
at responding so I don't really see a problem.

> We provide links on our website as a convenience, not as endorsement.

Do we?  For the software catalogue we explicitly say that we don't endorse any
software linked to but we don't do that anywhere on the PostgreSQL downloads
section.  Since these links are very much curated, I would think it reasonable
for users to think of them as endorsed by PGDG.

cheers ./daniel

Re: Installation instructions vs binaries

[Magnus Hagander]

On Tue, Oct 6, 2020 at 1:58 PM Daniel Gustafsson  wrote:

> > On 15 Sep 2020, at 02:43, David G. Johnston 
> wrote:
> > On Tue, Sep 8, 2020 at 8:05 AM Magnus Hagander  > wrote:
>
> > That leaves just the part of adding the actual new chapter of my patch.
> PFA. Thoughts on that?
>
> +1 on this version of the patch.
>
> It seems a bit odd to me to capitalize Download, but since it's the name
> of the
> referenced section I guess it's ok. Personally I'd have lowercased it.
> +  the Download section on the PostgreSQL
> website at
>

Yeah, that was based on the fact that it's like that on the website. But I
agree, it's a bit weird. I'll go change it.

Thanks to you both, pushed!


>
> > I kinda want to be blunt, though, and point out that if the user is
> using a pre-packaged version that the packager, and not the core team,
> accepts responsibility for problem reports related to installation, on
> their support channel.  Please don't use pg-bugs.
>
> I don't think it's reasonable to expect users to be able to separate bugs
> caused by the installer and supporting scripts/wrappers, and those by for
> example initdb.  AFAICR it's mostly the Windows installer which we get
> reports
> for on -bugs, and the devs responsible for said installer have been quite
> quick
> at responding so I don't really see a problem.
>

In some cases they probably can, but not in all cases. We do have people
reporting debian isssues directly to debian and redhat issues directly to
either redhat or our rpm packagers. Just not always.

We need a better workflow for reporting that, but this should really be
coded into the website (I have a draft patch somewhere that I never
finished), and not in the documentation. Because just saying "go somewhere
else" doesn't help anybody, unless we can also tell them where this
"somewhere else" is.


> We provide links on our website as a convenience, not as endorsement.
>
> Do we?  For the software catalogue we explicitly say that we don't endorse
> any
> software linked to but we don't do that anywhere on the PostgreSQL
> downloads
> section.  Since these links are very much curated, I would think it
> reasonable
> for users to think of them as endorsed by PGDG.
>

The things we have listed in the main download section on our website is
definitely being endorsed by the project. And as you say, the product
catalogue is different.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/ 

Re: Forgotten quote signs in description of "array value as a literal constant"

[David G. Johnston]

On Mon, Oct 5, 2020 at 9:32 AM PG Doc comments form 
wrote:

> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/12/arrays.html
> Description:
>
> Documentation should mention single quotes in "array value as a literal
> constant" description.
>

The choice to not repeat the fact that string literals in PostgreSQL are
always written with surrounding single quotes (or dollar-quoting if one so
chooses) does not seem problematic, especially given the explicitness of
the examples.  Much of the documentation rightfully assumes one has read
and memorized the syntax for writing a literal constant.

David J.

nondeterministic collations and statistics and pattern matching

[PG Doc comments form]

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/12/collation.html
Description:

If exists statistic with nondeteministic collation inherited from column
collation then using pattern matching with collation will give an error.
There is no information about it. ((
I have seen this thread
https://www.postgresql.org/message-id/flat/CAAFmbbOvfi%3DwMM%3D3qRsPunBSLb8BFREno2oOzSBS%3DmzfLPKABw%40mail.gmail.com
But I can't apply this patch for some reasons.
If I knew about the problem I would not use nondeterministic collations and
choose another way.

Re: nondeterministic collations and statistics and pattern matching

[Tom Lane]

PG Doc comments form  writes:
> If exists statistic with nondeteministic collation inherited from column
> collation then using pattern matching with collation will give an error.

Yeah, that's a known problem we fixed months ago.

> There is no information about it. ((

Other than the 12.4 release note entry, you mean?

> I have seen this thread
> https://www.postgresql.org/message-id/flat/CAAFmbbOvfi%3DwMM%3D3qRsPunBSLb8BFREno2oOzSBS%3DmzfLPKABw%40mail.gmail.com
> But I can't apply this patch for some reasons.

What is your point exactly?  You think the documentation should
describe your unspecified reasons for not updating to 12.4?
I'm afraid I'm not a telepath.

regards, tom lane

Re: Request for further clarification on synchronous_commit

[Bruce Momjian]

On Fri, Aug 21, 2020 at 04:15:39PM -0400, Bruce Momjian wrote:
> How is this for a table?
> 
> -- local --   --- standbys 
> --
>  durable  query  durable commit  durable 
> commit
>  commitconsistency   after OS crash  after PG 
> crash
>   remote_apply  X   X   X  X
>   onX   X  X
>   remote_write  X  X
>   local X
>   off

I have created the attached doc patch which I plan to apply to all
supported versions of Postgres.

-- 
  Bruce Momjian  https://momjian.us
  EnterpriseDB https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index ee914740cc..2768c85a96 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2703,14 +2703,26 @@ include_dir 'conf.d'
   
   

-Specifies whether transaction commit will wait for WAL records
-to be written to disk before the command returns a success
-indication to the client.  Valid values are on,
-remote_apply, remote_write, local,
-and off.  The default, and safe, setting
-is on.  When off, there can be a delay between
-when success is reported to the client and when the transaction is
-really guaranteed to be safe against a server crash.  (The maximum
+Specifies how much WAL processing must complete before
+the database server returns a success
+indication to the client.  Valid values are
+remote_apply, on
+(the default), remote_write,
+local, and off.
+   
+
+   
+If synchronous_standby_names is empty,
+the only meaningful settings are on and
+off;  remote_apply,
+remote_write and local
+all provide the same local synchronization level
+as on.  The local behavior of all
+non-off modes is to wait for local flush of WAL
+to disk.  In off mode, there is no waiting,
+so there can be a delay between when success is reported to the
+client and when the transaction is later guaranteed to be safe
+against a server crash.  (The maximum
 delay is three times .)  Unlike
 , setting this parameter to off
 does not create any risk of database inconsistency: an operating
@@ -2722,38 +2734,40 @@ include_dir 'conf.d'
 exact certainty about the durability of a transaction.  For more
 discussion see .

+

-If  is non-empty, this
-parameter also controls whether or not transaction commits will wait
-for their WAL records to be replicated to the standby server(s).
-When set to on, commits will wait until replies
+If  is non-empty,
+synchronous_commit also controls whether
+transaction commits will wait for their WAL records to be
+processed on the standby server(s).
+   
+
+   
+When set to remote_apply, commits will wait
+until replies from the current synchronous standby(s) indicate they
+have received the commit record of the transaction and applied
+it, so that it has become visible to queries on the standby(s),
+and also written to durable storage on the standbys.  This will
+cause much larger commit delays than previous settings since
+it waits for WAL replay.  When set to on,
+commits wait until replies
 from the current synchronous standby(s) indicate they have received
-the commit record of the transaction and flushed it to disk.  This
+the commit record of the transaction and flushed it to durable storage.  This
 ensures the transaction will not be lost unless both the primary and
 all synchronous standbys suffer corruption of their database storage.
-When set to remote_apply, commits will wait until replies
-from the current synchronous standby(s) indicate they have received the
-commit record of the transaction and applied it, so that it has become
-visible to queries on the standby(s).
 When set to remote_write, commits will wait until replies
 from the current synchronous standby(s) indicate they have
-received the commit record of the transaction and written it out to
-their operating system. This setting is sufficient to
-ensure data preservation even if a standby instance of
-PostgreSQL were to crash, but not if the standby
-suffers an operating-system-level crash, since the data has not
+received the commit record of the transaction and written it to
+their file systems. This setting ensures d