Supported versions missing at the top of the page

[Daniel Westermann (DWE)]

Hi,


please check here: https://www.postgresql.org/docs/10/progress-reporting.html


It only shows 9.6, 10 and 11 as "Supported Versions" on the top of the page.

==> Supported Versions: 
Current 
(11) / 
10 / 
9.6


Regards

Daniel

Re: Supported versions missing at the top of the page

[Magnus Hagander]

On Thu, Apr 4, 2019 at 10:24 AM Daniel Westermann (DWE) <
daniel.westerm...@dbi-services.com> wrote:

> Hi,
>
>
> please check here:
> https://www.postgresql.org/docs/10/progress-reporting.html
>
>
> It only shows 9.6, 10 and 11 as "Supported Versions" on the top of the
> page.
>
> ==> Supported Versions: Current
>  (11
> ) / 10
>  / 9.6
> 
>
>
>
That is because this page did not exist before version 9.6.

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

Re: Supported versions missing at the top of the page

[Daniel Westermann (DWE)]

On Thu, Apr 4, 2019 at 10:24 AM Daniel Westermann (DWE) 
mailto:daniel.westerm...@dbi-services.com>> 
wrote:

Hi,


please check here: https://www.postgresql.org/docs/10/progress-reporting.html


It only shows 9.6, 10 and 11 as "Supported Versions" on the top of the page.

==> Supported Versions: 
Current 
(11) / 
10 / 
9.6


>>That is because this page did not exist before version 9.6.

Stupid me, sorry for the noise

Re: Responsive images in pgweb docs

[Peter Eisentraut]

Here is a patch to improve this a bit.  It turns back on making the SVG
images in the HTML output scale with the page size.  I also added some
CSS stuff to make the width 75% on large screens for a more pleasing look.

This fixes it for the gin image.  The pagelayout image still doesn't
scale, presumably for the reasons you identified inside the SVG code.

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From e2647f228f7cb4b553e858b61a0e86f7740b627e Mon Sep 17 00:00:00 2001
From: Peter Eisentraut 
Date: Thu, 4 Apr 2019 13:13:30 +0200
Subject: [PATCH] Better scaling of images in HTML output

---
 doc/src/sgml/stylesheet-html-common.xsl | 3 ++-
 doc/src/sgml/stylesheet.css | 6 ++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/doc/src/sgml/stylesheet-html-common.xsl 
b/doc/src/sgml/stylesheet-html-common.xsl
index b105005235..f89f399129 100644
--- a/doc/src/sgml/stylesheet-html-common.xsl
+++ b/doc/src/sgml/stylesheet-html-common.xsl
@@ -13,8 +13,9 @@
 
 
 
+0
 
-
+
 pgsql-docs@lists.postgresql.org
 2
 
diff --git a/doc/src/sgml/stylesheet.css b/doc/src/sgml/stylesheet.css
index c355fbecac..8518839bac 100644
--- a/doc/src/sgml/stylesheet.css
+++ b/doc/src/sgml/stylesheet.css
@@ -102,3 +102,9 @@ var { font-family: monospace; font-style: italic; }
 acronym{ font-style: inherit; }
 
 .option{ white-space: nowrap; }
+
+@media (min-width: 800px) {
+  .mediaobject {
+width: 75%;
+  }
+}
-- 
2.21.0

REFRESH MATERIALIZED VIEW CONCURRENTLY interaction with ORDER BY

[PG Doc comments form]

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.

Re: Responsive images in pgweb docs

[Jonathan S. Katz]

On 4/4/19 7:17 AM, Peter Eisentraut wrote:
> Here is a patch to improve this a bit.  It turns back on making the SVG
> images in the HTML output scale with the page size.  I also added some
> CSS stuff to make the width 75% on large screens for a more pleasing look.
> 
> This fixes it for the gin image.  The pagelayout image still doesn't
> scale, presumably for the reasons you identified inside the SVG code.

Tested against the local patch I have for pgweb for importing the docs
with appropriate classes. The GIN SVG does indeed scale properly, thanks!

As you mention, pagelayout still does not properly scale as it needs the
fix to scale.

Given you kept the gin.svg as is and that has some of the widths on it,
I'd propose we just add the viewbox on pagelayout.svg, i.e.

viewBox="0.00 0.00 610.00 210.00"

Fix attached. I tested this in both the HTML build and with the import
into pgweb with new patch, and it scaled correctly.

Thanks,

Jonathan


From cc29aa43269ba7beb11a61aa93096698540af179 Mon Sep 17 00:00:00 2001
From: "Jonathan S. Katz" 
Date: Thu, 4 Apr 2019 12:21:38 -0400
Subject: [PATCH 2/2] Make pagelayout.svg scalable based viewport.

---
 doc/src/sgml/images/pagelayout.svg | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/doc/src/sgml/images/pagelayout.svg 
b/doc/src/sgml/images/pagelayout.svg
index 6b819a553e..3cf89f0a14 100644
--- a/doc/src/sgml/images/pagelayout.svg
+++ b/doc/src/sgml/images/pagelayout.svg
@@ -3,6 +3,7 @@
 xmlns='http://www.w3.org/2000/svg'
 width='610'
 height='210'
+viewBox='0.00 0.00 610.00 210.00'
 shape-rendering='geometricPrecision'
 version='1.0'>
   
@@ -37,4 +38,4 @@
 
 
   
-
\ No newline at end of file
+
-- 
2.14.3 (Apple Git-98)



signature.asc
Description: OpenPGP digital signature

Building Source from windows clarification

[PG Doc comments form]

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/11/install-windows-full.html
Description:

On the page ->
https://www.postgresql.org/docs/9.0/install-windows-full.html
My first two items are in reference to the paragraph below: 
If you wish to build a 64-bit version, you must use the 64-bit version of
the command, and vice versa. In the Microsoft Windows SDK, start the CMD
shell listed under the SDK on the Start Menu. In recent SDK versions you can
change the targeted CPU architecture, build type, and target OS by using the
setenv command, e.g. setenv /x86 /release /xp to target Windows XP or later
with a 32-bit release build. See /? for other options to setenv.

1) It is unclear what CMD shell to launch. For me it is called either "x86
Native Tools Command Prompt for VS 2017" or "x64 Native Tools Command Prompt
for VS 2017". This is different than the "Developer Command Prompt for VS
2017" (Which wouldn't build for the correct architecture, there's a note on
MSDN documentation about not using env variables to specify the target
platform anymore)
2) It is unclear what setenv is and how to get it (I think I found it, but
it is quite old, and unnecessary).
3) The following line should be bold or larger than the text around it. ->
"The following additional products are not required to get started, but are
required to build the complete package. Use the config.pl file to specify
which directories the libraries are available in."

Clarification to pg_upgrade docs on reverting to old cluster

[Daniel Gustafsson]

Reading the pg_upgrade reference page, I get the feeling that one of the
bullets under "Reverting to old cluster" is a bit thin on detail to be helpful
to newcomers:

"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."

This is perfectly correct, but it fails to provide information on what to do
next in case reverting is in fact what the user wants.  The attached patch adds
a short sentence saying the old cluster should be restored from backups at this
point.

cheers ./daniel


pg_upgrade_revert_cluster.patch
Description: Binary data