Re: Release note trimming: another modest proposal

[Tom Lane]

"Jonathan S. Katz"  writes:
> On 2/4/19 11:12 AM, Tom Lane wrote:
>> Just for the record, this change causes the time to build HEAD's
>> HTML documentation to drop from ~120 sec to ~95 sec for me; the
>> size of the resulting html/ directory drops from 21MB to 15MB,
>> while the PDF output goes from 17MB to 12.2MB.  I didn't try to
>> measure the impact on tarball size, but it should be noticeable.

> Wow, 28-29% reduction in the file sizes, and 20% reduction in build
> time! Nice.

For amusement's sake (well, and to be sure I'd not broken anything)
I ran tarball builds on the various branch heads, and got

-rw-r--r-- 1 pgsql pgsql 18929153 Feb  5 00:27 postgresql-10.6.tar.bz2
-rw-r--r-- 1 pgsql pgsql 19703728 Feb  5 00:25 postgresql-11.1.tar.bz2
-rw-r--r-- 1 pgsql pgsql 16858141 Feb  5 00:32 postgresql-9.4.20.tar.bz2
-rw-r--r-- 1 pgsql pgsql 17506811 Feb  5 00:30 postgresql-9.5.15.tar.bz2
-rw-r--r-- 1 pgsql pgsql 18737381 Feb  5 00:29 postgresql-9.6.11.tar.bz2

(The minor numbers are lies, since we've not done a version_stamp.pl run
recently.)  The last real releases were

-rw-r--r--. 1 tgl tgl 20350612 Nov  5 17:11 postgresql-10.6.tar.bz2
-rw-r--r--. 1 tgl tgl 21263173 Nov  6 19:03 postgresql-11.1.tar.bz2
-rw-r--r--. 1 tgl tgl 17905682 Nov  5 17:11 postgresql-9.4.20.tar.bz2
-rw-r--r--. 1 tgl tgl 18707696 Nov  5 17:11 postgresql-9.5.15.tar.bz2
-rw-r--r--. 1 tgl tgl 20009048 Nov  5 17:11 postgresql-9.6.11.tar.bz2

so this change got us about 6%-7% savings in post-compression tarball size.
This isn't quite apples to apples of course, since the new builds include
code fixes since November ... but patches seldom make things smaller, so
if anything this is understating the savings.

regards, tom lane

Re: Release note trimming: another modest proposal

[Jonathan S. Katz]

On 2/4/19 5:23 PM, Tom Lane wrote:
> "Jonathan S. Katz"  writes:
>> On 2/4/19 4:25 PM, Tom Lane wrote:
>>> After a bit more thought, I'm inclined to propose that the policy be
>>> that we *don't* update the surviving back branches for branch retirement.
> 
>> ...so I guess in turn, we would not update back branches with newer
>> releases as well, i.e. adding references about 12 to 10? That makes
>> sense, and eases some of the burden on releases.
> 
> No, I definitely didn't have any intention of putting in forward
> references to later releases.  That seems a bit weird.

Agreed. Anyway, I like the overall solution: +1

Thanks for writing the patch,

Jonathan



signature.asc
Description: OpenPGP digital signature

Re: Release note trimming: another modest proposal

[Tom Lane]

"Jonathan S. Katz"  writes:
> On 2/4/19 4:25 PM, Tom Lane wrote:
>> After a bit more thought, I'm inclined to propose that the policy be
>> that we *don't* update the surviving back branches for branch retirement.

> ...so I guess in turn, we would not update back branches with newer
> releases as well, i.e. adding references about 12 to 10? That makes
> sense, and eases some of the burden on releases.

No, I definitely didn't have any intention of putting in forward
references to later releases.  That seems a bit weird.

regards, tom lane

Re: Release note trimming: another modest proposal

[Tom Lane]

"Jonathan S. Katz"  writes:
> On 2/4/19 11:12 AM, Tom Lane wrote:
>> It's not quite clear to me what the policy would be for removing
>> back-branch links from this list when old versions drop out of support.
>> Should we go back and remove them in surviving back branches, or just
>> change HEAD?

> Yeah, that was one of my first thoughts as I reviewed the patch. It's
> one of those "once-a-year" things that are easily forgotten (e.g. with
> EOL warnings, which is why we updated a few things around that). But as
> long as they're added to the process of wrapping for the release, it
> does not sound like its a huge burden.

After a bit more thought, I'm inclined to propose that the policy be
that we *don't* update the surviving back branches for branch retirement.
The new wording in release.sgml should be adjusted to clarify this,
along the lines of

Release notes for prior release branches can be found on the
PostgreSQL web site.  At the time of release of version 12,
these were the supported prior release branches:



Release notes for older branches can be found at
.

In this way, the prior-release notes section just provides some handy
links for recent past releases, and isn't purporting to offer
up-to-the-minute info on what's in support.

regards, tom lane

Re: Release note trimming: another modest proposal

[Jonathan S. Katz]

On 2/4/19 11:12 AM, Tom Lane wrote:
> "Jonathan S. Katz"  writes:
>> On 1/26/19 10:06 AM, Tom Lane wrote:
>>> If I haven't heard objections, I'll see about making this happen
>>> during the first week of Feb (after the CF closes, but before
>>> it's time to do the February releases' notes).
> 
>> Thank you! I was hoping to take a crack at doing this, but I would not
>> be able to do so in the above timeline. However, I should be able to review.
> 
> Attached is a diff showing what I'm thinking about, for HEAD; each
> active back branch would get a similar change.  I'd also "git rm"
> now-unreferenced files in relevant branches, but that'd just bulk up
> the diff so I've not shown it here.

Thanks on all accounts. I reviewed and its along the lines of what I was
thinking as well. The documentation in release.sgml on how to create
things is clear. I did not try applying the patch, but syntactically it
passes the eyeball test.


> It's not quite clear to me what the policy would be for removing
> back-branch links from this list when old versions drop out of support.
> Should we go back and remove them in surviving back branches, or just
> change HEAD?

Yeah, that was one of my first thoughts as I reviewed the patch. It's
one of those "once-a-year" things that are easily forgotten (e.g. with
EOL warnings, which is why we updated a few things around that). But as
long as they're added to the process of wrapping for the release, it
does not sound like its a huge burden.


> Note that this would change our workflow for release notes a bit,
> in that real editing work would happen in the back branches, rather
> than them just getting copies of text from HEAD.  I don't see a big
> problem there, but it's a bit different from how we've traditionally
> done things.

I guess one way to look at it: overhead of adding these additional
changes vs. overhead saved with build times + tarball size? Are the
extra X minutes of developer time worth it?

> 
> Just for the record, this change causes the time to build HEAD's
> HTML documentation to drop from ~120 sec to ~95 sec for me; the
> size of the resulting html/ directory drops from 21MB to 15MB,
> while the PDF output goes from 17MB to 12.2MB.  I didn't try to
> measure the impact on tarball size, but it should be noticeable.

Wow, 28-29% reduction in the file sizes, and 20% reduction in build
time! Nice.

Jonathan



signature.asc
Description: OpenPGP digital signature

Re: Release note trimming: another modest proposal

[Tom Lane]

"Jonathan S. Katz"  writes:
> On 1/26/19 10:06 AM, Tom Lane wrote:
>> If I haven't heard objections, I'll see about making this happen
>> during the first week of Feb (after the CF closes, but before
>> it's time to do the February releases' notes).

> Thank you! I was hoping to take a crack at doing this, but I would not
> be able to do so in the above timeline. However, I should be able to review.

Attached is a diff showing what I'm thinking about, for HEAD; each
active back branch would get a similar change.  I'd also "git rm"
now-unreferenced files in relevant branches, but that'd just bulk up
the diff so I've not shown it here.

It's not quite clear to me what the policy would be for removing
back-branch links from this list when old versions drop out of support.
Should we go back and remove them in surviving back branches, or just
change HEAD?

Note that this would change our workflow for release notes a bit,
in that real editing work would happen in the back branches, rather
than them just getting copies of text from HEAD.  I don't see a big
problem there, but it's a bit different from how we've traditionally
done things.

Just for the record, this change causes the time to build HEAD's
HTML documentation to drop from ~120 sec to ~95 sec for me; the
size of the resulting html/ directory drops from 21MB to 15MB,
while the PDF output goes from 17MB to 12.2MB.  I didn't try to
measure the impact on tarball size, but it should be noticeable.

regards, tom lane

diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index 5dfdf54..a03ea14 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -166,22 +166,6 @@
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
 
 
 
diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml
index 4055adf..cd12e1b 100644
--- a/doc/src/sgml/release.sgml
+++ b/doc/src/sgml/release.sgml
@@ -70,27 +70,78 @@ For new features, add links to the documentation sections.
   
 
 
+
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+ 
+  Prior Releases
+
+  
+   Release notes for currently-supported previous release series can be
+   found at:
+
+   
+
+ 
+  PostgreSQL 11:
+  https://www.postgresql.org/docs/11/release.html;>
+   https://www.postgresql.org/docs/11/release.html
+  
+ 
+
+
+
+ 
+  PostgreSQL 10:
+  https://www.postgresql.org/docs/10/release.html;>
+   https://www.postgresql.org/docs/10/release.html
+  
+ 
+
+
+
+ 
+  PostgreSQL 9.6:
+  https://www.postgresql.org/docs/9.6/release.html;>
+   https://www.postgresql.org/docs/9.6/release.html
+  
+ 
+
+
+
+ 
+  PostgreSQL 9.5:
+  https://www.postgresql.org/docs/9.5/release.html;>
+   https://www.postgresql.org/docs/9.5/release.html
+  
+ 
+
+
+
+ 
+  PostgreSQL 9.4:
+  https://www.postgresql.org/docs/9.4/release.html;>
+   https://www.postgresql.org/docs/9.4/release.html
+  
+ 
+
+   
+  
+
+  
+   Release notes for out-of-support release series can be found at
+   https://www.postgresql.org/docs/manuals/archive/;>
+https://www.postgresql.org/docs/manuals/archive/
+   
+  
+ 
 
 

Re: .pgpass

[Andres Leon Rangel]

Thanks Daniel
＿
   [ Have a blessed day! ]   
    My Profile  
Andres Leon-Rangel
 +64 027-498-1162
턗


On Thu, 10 Jan 2019 at 23:02, Daniel Gustafsson  wrote:

> > On 10 Jan 2019, at 04:45, PG Doc comments form 
> wrote:
> >
> > The following documentation comment has been logged on the website:
> >
> > Page: https://www.postgresql.org/docs/10/libpq-pgpass.html
> > Description:
> >
> > I kindly suggest to let me edit this part to create examples such as
> > pg_restore -h HOST -p PORT -U SUPERUSERNAME -C -d postgres
> > DBtoRESTORE.BACKUPEXTENSION
> >
> > this will be like generalized examples that users can replicate.
>
> The documentation isn’t edited online, but is contained in the postgres
> source
> repository.  If you want to edit it you will have to clone the repository
> and
> propose a patch with your changes on the pgsql-docs mailinglist.  The
> “Working
> with Git” article on the postgres wiki can be a good place to start if you
> are
> new to working in the source repository.
>
> cheers ./daniel