Re: tools.ietf.org is decommissioned and our links are redirected
On Wed, Apr 3, 2024 at 1:18 PM Daniel Gustafsson wrote: > The tools.ietf.org server which we use for all RFC/BCP links in the docs > has > been decommissioned, and our links are 301 redirected to the new locations > (datatracker. and rfc-editor.). To avoi another network roundtrip for our > readers, the attached patch updates the links to their new respective > locations. > +1. Extra round-trips are annoying. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Broken link in pgcrypto documentation
On Tue, Feb 13, 2024 at 9:08 PM Tom Lane wrote: > > Daniel Gustafsson writes: > > On 13 Feb 2024, at 20:42, Tom Lane wrote: > >> I'm a little dubious about the "Technical References" list right below > >> it, too. The RFC references are probably useful and stable, and maybe > >> the wikipedia ref is OK, but I have little faith in either the > >> stability or the long-term relevance of the other two links. > > > Not even those are all that stable, while the RFCs' in question haven't been > > replaced they have all been updated with new RFC's which we don't link to. > > I > > think we are better off removing them as well and leaving reading up on > > security/crypto subject an exercise for the reader. > > Good point. Nuking both lists works for me. +1. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Re: Broken link in pgcrypto documentation
On Tue, Feb 13, 2024 at 7:12 PM Daniel Gustafsson wrote: > > > On 12 Feb 2024, at 13:55, PG Doc comments form > > wrote: > > > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/16/pgcrypto.html > > Description: > > > > I was going through the links in pgcrypto documentation and I realized that > > one of the links at Useful Reading section do not work. > > Thanks for the report! > > However, I wonder if we aren't better off removing the "Useful Reading" > section > altogether? The field of crypto is continuously advancing and keeping a stale > 10+ year old list of links is unlikely to provide more insights than what more > curated sites can do. +1. I don't think it's the job of a postgres contrib module to maintain that. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Re: Incorrect mention of number of columns?
On Fri, Nov 3, 2023 at 5:09 PM Daniel Westermann (DWE)
wrote:
>
> Hi,
>
> from the limits page in the docs:
> https://www.postgresql.org/docs/current/limits.html
>
> "...but a tuple of 1600 bigint columns would consume 12800 bytes and would
> therefore not fit inside a heap page".
>
> Creating a table with 1600 bigint columns does work with a 8k blocksize:
>
> $ cat gen_tab.sh
> #!/bin/bash
> AMOUNT_OF_COLS=$1
> DATA_TYPE=$2
> STATEMENT="create table t ( "
> for (( i=1 ; i<${AMOUNT_OF_COLS} ; i++ ));
> do
> STATEMENT+=" col${i} ${DATA_TYPE},"
> done
> STATEMENT+="col${AMOUNT_OF_COLS} ${DATA_TYPE} );"
> echo ${STATEMENT}
>
> .$ /gen_tab.sh 1600 bigint > a.sql
>
> $ psql -f a.sql
> CREATE TABLE
>
> $ psql -c "\d t"
> ...
> col1598 | bigint | | |
> col1599 | bigint | | |
> col1600 | bigint | | |
>
> Am I missing something?
It will fail when you try to insert data in it.
//Magnus
Tightening the trust auth advice
The page at https://www.postgresql.org/docs/current/auth-trust.html goes through some length to explain why Trust is sometimes a good idea. Is it really though? And in particular, aren't there better choices? As a first step, I think we should put a box on the page explicitly saying that that trust, unless limited in pg_hba, will allow any user to become superuser which allows them to bypass all other security restrictions. Second, we're kind of going out of our way to recommend setting unix socket permissions etc -- in those cases, wouldn't it in almost every case just be better for the user to use "peer" auth instead of trust, and we should recommend them to use that instead? Is it really any less appropriate and/or convenient? (It was listed as appropriate back in 2001 in 6f0f5bf2fbe, but the world has changed a bit in 20+ years..) And finally, the sentence "It is seldom reasonable to use trust for any TCP/IP connections other than those from localhost (127.0.0.1)." should probably be amended with an ", and only reasonable for localhost if you trust every single user on the host"? Thoughts? I'll be happy to work up a patch if there's agreement on the general idea. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: No multi range functions on version 12
On Thu, Dec 15, 2022 at 12:45 PM PG Doc comments form < nore...@postgresql.org> wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/15/rangetypes.html > Description: > > Hello, according to the documentation, Postgres 12 should have multi range > functions. However, in my installation of Postgres 12.12, I don't have any > multi range function. When I ran them Postgres said they didn't exist and I > can't see them when querying through pg_proc. > What documentation says they should be in version 12? The page you commented on is about PostgreSQL 15, and multiranges were not present in version 12... -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: PostgreSQL pdf shows 12.11 instead of 12.12
On Tue, Aug 16, 2022 at 7:48 AM William Sescu (Suva) wrote: > > Hello % > > > > The PostgreSQL pdf (A4) shows 12.11 instead of 12.12 > > > > https://www.postgresql.org/files/documentation/pdf/12/postgresql-12-A4.pdf > > This link shows 12.12 for me. Perhaps you have some cache in your browser that needs to be cleared? //Magnus
Re: Remove recommendation for nightly VACUUM
On Mon, Jun 27, 2022 at 5:36 PM Peter Geoghegan wrote: > On Mon, Jun 27, 2022 at 1:32 AM Magnus Hagander > wrote: > >> Looking at the Git history, most of that paragraph is from a time > >> when autovacuum did not yet exist or was much less reliable than it > >> is now. So I suggest removing all that and pointing to autovacuum > >> instead, as done in the attached patch. > > > > > > Agred. A nightly vacuum is definitely not something for "most people" > anymore. > > +1. > > The VACUUM documentation needs to be totally overhauled. This is a start. > Agred, let's do partial improvement and not wait for a rewrite. Thus, applied! Thanks! -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Remove recommendation for nightly VACUUM
On Mon, Jun 27, 2022 at 8:31 AM Laurenz Albe wrote: > A customer recently pointed me to > https://www.postgresql.org/docs/current/sql-vacuum.html > and asked if I agree with the statement there that a nightly > scheduled VACUUM were a good idea: > > "We recommend that active production databases be vacuumed frequently > (at least nightly), in order to remove dead rows. After adding or > deleting a large number of rows, it might be a good idea to issue a > VACUUM ANALYZE command for the affected table. This will update the > system catalogs with the results of all recent changes, and allow the > PostgreSQL query planner to make better choices in planning queries." > > Looking at the Git history, most of that paragraph is from a time > when autovacuum did not yet exist or was much less reliable than it > is now. So I suggest removing all that and pointing to autovacuum > instead, as done in the attached patch. > Agred. A nightly vacuum is definitely not something for "most people" anymore. But also. "active production databases". Surely we recommend regular vacuum in *all* databases when it's primarily driven by autovacuum? At least all active. But there's nothing special about "production"? Since we're tweaking the wording, I would suggest removing that reference as well. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: No search results for "BETWEEN"
On Fri, Jun 24, 2022 at 4:40 PM Tom Lane wrote: > PG Doc comments form writes: > > Searching for "the between predicate simplifies range tests" does turn > > up a hit for that page, so it's indexed, but the words "The BETWEEN" are > > not set in bold in the search result. Perhaps "BETWEEN" is being treated > > as a stop word, even though it's capitalized and an SQL keyword? > > A quick grep shows that if "between" weren't a stopword, it would > produce almost 600 hits in our core docs, most of which are not what > you're looking for. So I concur with somebody's apparent decision > to make it a stopword. > It is a standard stopword in the snowball stemmers we ship, sadly. I don't think we have an easy way to say "use this dictionary and it's stopwords, except these couple of words that we want to not be stopwords"? Other than having to maintain a separate copy of the whole file and then forgetting to update it? //Magnus
Re: Should we really recommend "-A md5 or -A password"?
On Tue, May 31, 2022 at 3:57 PM Jonathan S. Katz wrote: > On 5/31/22 8:35 AM, Magnus Hagander wrote: > > > > > > On Tue, May 31, 2022 at 2:29 PM Daniel Westermann (DWE) > > > <mailto:daniel.westerm...@dbi-services.com>> wrote: > > > > Hi, > > > > I just came across this: > > "Also, specify -A md5 or -A password so that the default trust > > authentication mode is not used;" > > https://www.postgresql.org/docs/current/creating-cluster.html > > <https://www.postgresql.org/docs/current/creating-cluster.html> > > > > Shouldn't we change that to "-A scram-sha-256" ? > > > > > > Yes I think we absolutely should! > > +1 > > Proposed patch attached. This also removes "-A password" from that > sentence as well. > Applied and backpatched to 14. Thanks! -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Should we really recommend "-A md5 or -A password"?
On Tue, May 31, 2022 at 2:29 PM Daniel Westermann (DWE) < daniel.westerm...@dbi-services.com> wrote: > Hi, > > I just came across this: > "Also, specify -A md5 or -A password so that the default trust > authentication mode is not used;" > https://www.postgresql.org/docs/current/creating-cluster.html > > Shouldn't we change that to "-A scram-sha-256" ? > Yes I think we absolutely should! -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: documentation typo
On Sun, Jan 30, 2022 at 1:39 PM PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/lo-interfaces.html > Description: > > I assume "inv_oid = lo_creat(conn, INV_READ|INV_WRITE);" should be "inv_oid > = lo_create(conn, INV_READ|INV_WRITE);", right? > https://www.postgresql.org/docs/10/lo-interfaces.html#LO-CREATE lo_creat() and lo_create() are two different functions. They do the same thing but take different parameters. It might be worth splitting that part into one section with the current function (lo_create) and then a separate section with the backwards-compatible lo_creat function though -- I can see how it's easy to come to the conclusion you did from reading it, and that could be made a lot more clear. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Re: Dead link to MinGW in Windows documentation
On Mon, Jan 17, 2022 at 11:25 AM Daniel Gustafsson wrote: > > > On 17 Jan 2022, at 07:21, Liam Bowen wrote: > > > > From https://www.postgresql.org/docs/14/install-windows-full.html -- > > > > > Both Bison and Flex are included in the msys tool suite, available from > > > http://www.mingw.org/wiki/MSYS as part of the MinGW compiler suite. > > > > Aforementioned link is to a domain squatter. > > > > Perhaps MSYS2 could be used instead? https://packages.msys2.org/base > > Agreed, that seems like a better URL to refer to. Unless there are objections > I will fix that in all supported branches. +1. Note that there are two references to mingw.org -- also one in https://www.postgresql.org/docs/14/installation-platform-notes.html as well. They should both be fixed. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com
Re: Typo in "27.2.8. Synchronous Replication"
On Mon, Jan 3, 2022 at 1:40 PM Eric Mutta wrote: > > Hi Magnus, happy new year! Thanks for pushing the fix. > > Coming from an SQL Server background where the docs are hosted on GitHub and > minor changes like this can be made by simply submitting a pull request, I am > wondering is there anything similar for the Postgres docs? > > Going through a mailing list just to fix a typo feels like a lot of overhead! Hi! Personally, I would find sending an email to a mailing list or like you did, filling out the form on the website, would be *less* overhead than having to do a Pull Request (which would include checkout, verifying builds etc, no?). Can you enlighten me on exactly which part of the flow of that you think would make it easier? Perhaps it's something we can adopt something out of to make it easier for us as well. But I wonder if it more has to do with the structure of the docs than the actual tool? (That is, the error is on warm-standby.html, but the source is actually in a file called high-availability.sgml) //Magnus
Re: Typo in "27.2.8. Synchronous Replication"
On Mon, Dec 27, 2021 at 12:07 AM PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/14/warm-standby.html > Description: > > The following sentence: > > > The minimum wait time is the round-trip time **between primary to > standby.** > > Should either end with "...between primary AND standby" or end with "...FROM > primary to standby". That's indeed correct. Fix pushed. I went with "primary and standby" because that's the terminology used elsewhere in the same file. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Re: [PATCH] fix ICU explorer link in locale documentation
On Sun, Apr 4, 2021 at 9:53 AM Anton Voloshin wrote: > > Hello, > > Existing Postgres documentation states in doc/src/sgml/charset.sgml: > The https://ssl.icu-project.org/icu-bin/locexp";>ICU Locale > Explorer can be used to check the details of a particular locale > definition. > > But the link is broken (SSL certificate does not include > ssl.icu-project.org as allowed name). Correct link is, I believe, > https://icu4c-demos.unicode.org/icu-bin/locexp > > Attached patch fixes the broken link. https://icu4c-demos.unicode.org/icu-bin/locexp generates a 404 for me now. This might be something temporary though, because AFAICT it's where you end up when you follow the links from the ICU git repo... -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Re: Wrong distance shown in miles for extension earthdistance
On Mon, Mar 22, 2021 at 9:27 AM PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/earthdistance.html > Description: > > Hi, > I have installed > CREATE EXTENSION CUBE; > CREATE EXTENSION earthdistance; > > Post which I ran the following query: > SELECT (POINT (19.974, 72.756)<@> POINT (19.195, 72.959)) AS DISTANCE; > > The answer came back as 21.17534 miles whereas the actual distance (as crow > flies) is 55.42 miles which I have checked from 2-3 websites. (Google maps > gives a greater distance which is travel by road & this value has been > ignored). > > I know both the places and the distance between both of them cannot be 22 > miles. It has to be in excess of 50 miles atleast. What am I missing? By your queasy it looks like you are comparing two points in the Norwegian Sea. I think you may have swapped your latitude and longitude, and are actually looking for: postgres=# SELECT (POINT (72.756, 19.974)<@> POINT (72.959, 19.195)) AS DISTANCE; distance 55.421996899143366 -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Re: set auto commit is not working
On Thu, Feb 25, 2021 at 5:06 PM PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/13/ecpg-sql-set-autocommit.html > Description: > > I tested with " PostgreSQL 13.2 on x86_64-pc-linux-gnu, compiled by gcc > (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5), 64-bit" > > The result is below. > > postgres=# set autocommit to off ; > ERROR: unrecognized configuration parameter "autocommit" > > > > I think the document must clearly say this is not supported; You are looking at the documentation for ECPG, but using psql. The ECPG documentation only applies to ECPG. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Re: CREATE TABLE typo
On Wed, Feb 17, 2021 at 12:58 PM Daniel Gustafsson wrote: > > Commit f2a69b352de introduced a small typo in the CREATE TABLE documentation, > fixed in the attached. Applied, thanks. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Re: Replace mention of FTP server with more up to date downloads location
On Fri, Jan 22, 2021 at 11:36 AM Daniel Gustafsson wrote: > > While looking at something else, I noticed that we still refer to the > "PostgreSQL FTP server" in the MSVC portion of the docs even though the FTP > server is long since gone. The attached diff changes it to refer to the > downloads section of the web site instead which seems more up to date. Applied, with changing the "on" to "in" per off-list discussion. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Re: Typo
On Wed, Jan 13, 2021 at 11:01 AM Michael Vastola wrote: > > Crap. Meant to include link. > > See > https://www.postgresql.org/docs/current/functions-string.html#id-1.5.8.10.7.2.2.28.1.1.1 > > On 1/12/21 10:59 PM, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/13/functions-string.html > > Description: > > > > Hi, > > *Really* tiny issue, but the two the functions listed here have unbalanced > > parenthesis. (Obviously this is super low priority.) That looks to be a mistake made in the conversion of the table formats, yeah. Fix applied, thanks for the report! -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Re: On what system does the postgresql docs run?
On Wed, Nov 4, 2020 at 9:55 AM PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/12/libpq-pgpass.html > Description: > > Hi, I really like the postgresql documentation system and am curious what it > is. After viewing source and digging around, I can't seem to determine what > it's running on. To be clear I am asking what publishing system is used to > edit and publish a page like the one below: > https://www.postgresql.org/docs/12/libpq-pgpass.html The PostgreSQL docs system uses docbook -- see https://www.postgresql.org/docs/current/docguide.html for some more information about it. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Re: Installation instructions vs binaries
Ah, yes it does. Thanks -- will close. //Magnus On Wed, Oct 21, 2020 at 5:40 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > Magnus, > > [offline] > > Does this resolve the 2020-11 commitfest entry? > > https://commitfest.postgresql.org/30/2726/ > > David J. > > On Tue, Oct 6, 2020 at 5:21 AM Magnus Hagander > wrote: > >> >> >> On Tue, Oct 6, 2020 at 1:58 PM Daniel Gustafsson wrote: >> >>> > On 15 Sep 2020, at 02:43, David G. Johnston < >>> david.g.johns...@gmail.com> wrote: >>> > On Tue, Sep 8, 2020 at 8:05 AM Magnus Hagander >> <mailto:mag...@hagander.net>> 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! >> >
Re: Fix PL/Lua link in External Projects appendix
On Fri, Oct 16, 2020 at 11:30 AM Daniel Gustafsson wrote: > > On 16 Oct 2020, at 11:26, Magnus Hagander wrote: > > > > On Fri, Oct 16, 2020 at 10:32 AM Daniel Gustafsson <mailto:dan...@yesql.se>> wrote: > > The PL/Lua repository we link to in the documentation has been updated > to say > > DEPRECATED, with a reference to a new repo within the same Github > organization. > > The attached patch updates the url in the postgres docs to point to the > current > > repo. > > > > Should the name of it perhaps also be updated to include the "ng" part? > > I don't think so, AFAICT it's only the repo which has been renamed and not > the > PL or the project. > Ah, OK, I think I misunderstood that part. I've pushed the patch. Thanks! -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Fix PL/Lua link in External Projects appendix
On Fri, Oct 16, 2020 at 10:32 AM Daniel Gustafsson wrote: > The PL/Lua repository we link to in the documentation has been updated to > say > DEPRECATED, with a reference to a new repo within the same Github > organization. > The attached patch updates the url in the postgres docs to point to the > current > repo. > Should the name of it perhaps also be updated to include the "ng" part? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Installation instructions vs binaries
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 <mailto:mag...@hagander.net>> 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/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: ssl file permission
On Sat, Sep 26, 2020 at 1:23 PM PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/12/libpq-ssl.html > Description: > > The instruction to use "chmod og-rwx" could leave the file with read > permission set. Elsewhere the suggestion is "chmod 600". > Not sure what you mean here -- how could it leave it with read permission set? (Obviously it could for the owner, but 0600 also includes read permissions for the owner) That said, it might be a good idea to be consistent since we seem to use a mix of different styles of chmod. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Possible mistake in backup documentation
On Fri, Sep 25, 2020 at 2:32 PM Laurenz Albe wrote: > On Tue, 2020-09-22 at 14:17 +, PG Doc comments form wrote: > > In "25.3.3.2. Making An Exclusive Low-Level Backup", you said that "The > > exclusive backup method is deprecated and should be avoided. Prior to > > PostgreSQL 9.6, this was the only low-level method available, but it is > now > > recommended that all users upgrade their scripts to use non-exclusive > > backups". But in the example in "25.3.6.1. Standalone Hot Backups" you > use > > the exclusive version of backup command. Is it a mistake or not? > > Yes, that's true. > Well, technically it is *correct*. It's just rather silly that we are using the deprecated API in the example. How about the attached patch? > > Perhaps that is too complicated, but I have no idea how to make it simpler. > For this example, can't we just show two sessions. That is, "in a psql, run pg_start_backup(). Then in a different session, copy all the files, and then back in psql run pg_stop_backup()" or such? This is still just an example of a low level operation, where the recommendation is (and is there iirc) to use a different tool for it already. > Ceterum censeo, we should not deprecate the exclusive backup API. > Well. We should depreciate the way it works now, but we should also provide a *better* way to solve the actual problem. This is not necessarily an API that looks the way the deprecated one looks -- the focus should be on providing a solution to the problem, not to un-deprecate the API. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Magic number for SSLRequest
On Fri, Sep 18, 2020 at 1:07 PM PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/11/protocol-message-formats.html > Description: > > On page: https://www.postgresql.org/docs/11/protocol-message-formats.html > > it says for SSLRequest packet: > > Int32(80877103) > The SSL request code. The value is chosen to contain 1234 in the most > significant 16 bits, and 5679 in the least significant 16 bits. > > I don't see how that works. 0x12345678 is 305,419,897. > > 80877103 decimal in hex is 0x04D2162F > It's 1234 and 5679, not 0x1234 and 0x5679. That is, it's decimal, not hexadecimal. 0x04D2 = 1234 0x162F = 5679 -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: replication wordsmithing / clarifications
On Sat, Sep 12, 2020 at 3:46 AM Michael Paquier wrote: > On Fri, Sep 11, 2020 at 07:16:43PM -0400, Robert Treat wrote: > > A recent discussion on slack prompted me to read through the > > high-availability section of the docs, turning in to some suggested > > changes that hopefully clarify how the various replication options > > work (specifically around logical and trigger-based solutions). A > > proposed patch is attached, lmk if you have questions. > > A portion of what you are suggesting here is in line with 9e101cf, > which looks like a good thing. Most of the changes look like > improvements to me, and here are some comments. > +1. > > + queries to a designated primary server. Operating on a > per-tablebasis, > + the primary server sends data changes (typically) asynchronously to > the > + replica node(s). Replica nodes can answer queries while the primary > is > Could it be better to use "one or more replica clusters" here? > In particular, why is the primary a "server" and the replica a "node"? That caught my eye for inconsistency -- but changing node to cluster will be equally inconsistent, just in a different way. Why not just call them both servers? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: typo in literature reference
On Thu, Sep 10, 2020 at 1:50 PM Daniel Gustafsson wrote: > > On 10 Sep 2020, at 11:26, PG Doc comments form > wrote: > > > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/12/biblio.html > > Description: > > > > Ullmann's classic should be > > > > [ull88] > > Principles of Database and Knowledge-Base Systems. > > Jeffrey D. Ullman. Volume 1. Computer Science Press. 1988. > > > > not > > > > [ull88] > > Principles of Database and Knowledge. > > Base Systems. Jeffrey D. Ullman. Volume 1. Computer Science Press. 1988. > > > > as Base Systems is not a subtitle > > Nice catch, it's been this way since 9474dd7ed6988924 which was committed > in > May 1999. The book does actually have a subtitle though, which is > "Classical > Database Systems". Fixed in the attached. > Thanks. Backpatched and pushed! -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Installation instructions vs binaries
On Tue, Sep 8, 2020 at 4:51 PM Tom Lane wrote: > Magnus Hagander writes: > > I think we're talking about a different repetitiveness. If I apply Davids > > suggestion to that patch, then instead of: > > > + > > + If you are using a pre-packaged version > > + of PostgreSQL, it may well have a specific > > + convention for where to place the data directory, and it may also > > + provide a script for creating the data directory. In that case you > > > It would say something like > > Pre-packaged versions of PostgreSQL may have a specific convention > > (rest unchanged). > > [ shrug... ] Well, I wrote that text, so naturally I like it the way > it is ;-). Perhaps a neutral observer would like the shorter version > better, not sure. But I think pluralizing "versions" is going to make > it harder to construct the rest of the sentence non-ambiguously. > You really only want to be talking about one data directory location > and one wrapper script. > Yeah, I guess it can work either way. I don't feel too strongly about that one, so I'll leave it to David to argue for that standpoint if he thinks it applies here as well. That leaves just the part of adding the actual new chapter of my patch. PFA. Thoughts on that? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/> diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml index 64b5da0070..463bdfd29c 100644 --- a/doc/src/sgml/filelist.sgml +++ b/doc/src/sgml/filelist.sgml @@ -36,6 +36,7 @@ + diff --git a/doc/src/sgml/install-binaries.sgml b/doc/src/sgml/install-binaries.sgml new file mode 100644 index 00..36405e74cc --- /dev/null +++ b/doc/src/sgml/install-binaries.sgml @@ -0,0 +1,24 @@ + + + Installation from Binaries + + + installation + binaries + + + + PostgreSQL is available in the form of binary + packages for most common operating systems today. When available, this is + the recommended way to install PostgreSQL for users of the system. Building + from source (see ) is only recommended for + people developing PostgreSQL or extensions. + + + + For an updated list of platforms providing binary packages, please visit + the Download section on the PostgreSQL website at + https://www.postgresql.org/download/";> and follow the + instructions for the specific platform. + + diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml index 11f5957aca..844ef2cbd2 100644 --- a/doc/src/sgml/install-windows.sgml +++ b/doc/src/sgml/install-windows.sgml @@ -11,7 +11,8 @@ It is recommended that most users download the binary distribution for Windows, available as a graphical installer package - from the PostgreSQL website. Building from source + from the PostgreSQL website at + https://www.postgresql.org/download/";>. Building from source is only intended for people developing PostgreSQL or extensions. diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml index 552303e211..ce9bdb1297 100644 --- a/doc/src/sgml/installation.sgml +++ b/doc/src/sgml/installation.sgml @@ -21,7 +21,7 @@ documentation. See standalone-profile.xsl for details. PostgreSQL using the source code distribution. If you are installing a pre-packaged distribution, such as an RPM or Debian package, ignore this chapter - and read the packager's instructions instead. + and see instead. diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml index c41ce9499b..730d5fdc34 100644 --- a/doc/src/sgml/postgres.sgml +++ b/doc/src/sgml/postgres.sgml @@ -154,6 +154,7 @@ break is not needed in a wider output rendering. + &installbin; &installation; &installw; &runtime;
Re: Installation instructions vs binaries
On Tue, Sep 8, 2020 at 4:27 PM Tom Lane wrote: > Magnus Hagander writes: > > And I think Davids comment about repetitive language would apply to yours > > as well, and should maybe be simplified there too? > > Per the discussion in the other thread, we concluded that being repetitive > was the only way to be sure people would see the material at all. > If you look at > > https://www.postgresql.org/docs/devel/runtime.html > > a lot of people are going to follow one of the section links before > they ever see any of the chapter head material. > I think we're talking about a different repetitiveness. If I apply Davids suggestion to that patch, then instead of: + + If you are using a pre-packaged version + of PostgreSQL, it may well have a specific + convention for where to place the data directory, and it may also + provide a script for creating the data directory. In that case you It would say something like Pre-packaged versions of PostgreSQL may have a specific convention (rest unchanged). //Magnus
Re: Installation instructions vs binaries
On Tue, Sep 8, 2020 at 4:06 PM Tom Lane wrote: > Magnus Hagander writes: > > Yeah, that makes a lot of sense. How about like this? > > Isn't this pretty duplicative of d2511d713? > Eh yes, I clearly missed that one -- that's what I get for forgetting to put it in the CF :) That said, I still think it's worthwhile to have a separate chapter on installing from binaries, ahead of the source one, rather than just a note in the source chapter -- and with proper links to the website. And I think Davids comment about repetitive language would apply to yours as well, and should maybe be simplified there too? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Installation instructions vs binaries
On Thu, Jul 16, 2020 at 6:25 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Wed, Jul 15, 2020 at 4:13 AM Magnus Hagander > wrote: > >> It's kind of strange that if you start your PostgreSQL journey by reading >> our instructions, you get nothing useful about installing PostgreSQL from >> binary packages other than "go ask somebody else about it". Yet we have >> pretty good step by step instructions on our *website* for it. >> >> Attached patch adds a chapter to the docs about installing from binaries, >> and refers those users to the website download instructions (and updates >> the Windows instructions to include an actual link to the website). >> >> It also adds mention of it in a few other places - -there are probably >> more that could use some help with that in the future. But I've seen a lot >> of people get confused by our documentation assuming everything is from >> source when it comes to initdb and pg_ctl that I think it's worth specially >> mentioning it there. >> > Dang, I forgot to add this to the cf page, so I forgot about it myself :) Thanks. Adding tips calling out common package-specific/handled pieces > seems ok. > > One typo for the patch as-is: > > + When PostgreSQL is installed using binary packages, starting and > stopping > +of the system is normally integrated with the service management on > the > +platform. Refer to the documentation for the documentation for these > +packages and the platform for more information. > > Remove "for the documentation" > Hah, yeah, that's cute. However, maybe we should avoid repeated use of the passive "When PostgreSQL > is installed using binary packages". Consider just: "PostgreSQL binary > packages". e.g., > > PostgreSQL binary packages normally include platform-appropriate service > management (starting and stopping). Consult the package documentation for > more information. > > (the other two can be rewording similarly if this is deemed better - all > three should be consistent). > Yeah, that makes a lot of sense. How about like this? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/> diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml index 64b5da0070..463bdfd29c 100644 --- a/doc/src/sgml/filelist.sgml +++ b/doc/src/sgml/filelist.sgml @@ -36,6 +36,7 @@ + diff --git a/doc/src/sgml/install-binaries.sgml b/doc/src/sgml/install-binaries.sgml new file mode 100644 index 00..36405e74cc --- /dev/null +++ b/doc/src/sgml/install-binaries.sgml @@ -0,0 +1,24 @@ + + + Installation from Binaries + + + installation + binaries + + + + PostgreSQL is available in the form of binary + packages for most common operating systems today. When available, this is + the recommended way to install PostgreSQL for users of the system. Building + from source (see ) is only recommended for + people developing PostgreSQL or extensions. + + + + For an updated list of platforms providing binary packages, please visit + the Download section on the PostgreSQL website at + https://www.postgresql.org/download/";> and follow the + instructions for the specific platform. + + diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml index 11f5957aca..844ef2cbd2 100644 --- a/doc/src/sgml/install-windows.sgml +++ b/doc/src/sgml/install-windows.sgml @@ -11,7 +11,8 @@ It is recommended that most users download the binary distribution for Windows, available as a graphical installer package - from the PostgreSQL website. Building from source + from the PostgreSQL website at + https://www.postgresql.org/download/";>. Building from source is only intended for people developing PostgreSQL or extensions. diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml index 552303e211..ce9bdb1297 100644 --- a/doc/src/sgml/installation.sgml +++ b/doc/src/sgml/installation.sgml @@ -21,7 +21,7 @@ documentation. See standalone-profile.xsl for details. PostgreSQL using the source code distribution. If you are installing a pre-packaged distribution, such as an RPM or Debian package, ignore this chapter - and read the packager's instructions instead. + and see instead. diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml index c41ce9499b..730d5fdc34 100644 --- a/doc/src/sgml/postgres.sgml +++ b/doc/src/sgml/postgres.sgml @@ -154,6 +154,7 @@ break is not needed in a wider output rendering. + &installbin; &installation; &installw; &runtime; diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index
Re: Installation on Cygwin
On Mon, Aug 31, 2020 at 5:52 PM Bruce Momjian wrote: > On Fri, Aug 28, 2020 at 09:40:59PM +0200, Daniel Gustafsson wrote: > > I happened to stumble over the Cygwin section of the installation docs, > and was > > surprised to see references to not entirely bleeding-edge Windows > versions: > > > > "The adduser command is not supported; use the appropriate user > management > > application on Windows NT, 2000, or XP. Otherwise, skip this step." > > > > Not knowing the first thing about Cygwin I might be out cycling here; it > does > > sound like it's about due for an update to reflect current versions of > Windows, > > or is this just relevant for older versions? Skimming backwards we > have, with > > various wordings, recommendeed against Cygwin since 8.0, the current > wording > > going back to 8.4 more or less unchanged. > It's cute that it also talks about doing things on "Windows NT" Any "non-NT" Windows has not existed for *many* years. > > I am thinking the list of operating systems should just be removed. > Are you referring to the whole section 16.7 in the 12 version ( https://www.postgresql.org/docs/current/installation-platform-notes.html)? I can agree with that, and say that maybe that type of content is better maintained on the wiki? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: typo in sentence
On Fri, Jul 24, 2020 at 3:28 PM PG Doc comments form
wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/12/manage-ag-overview.html
> Description:
>
> The sentence has a typo: "If one PostgreSQL server instance is to house
> projects or users that should be separate and for the most part unaware of
> each other, it is therefore recommended to put them into separate
> databases."
>
> The word "therefore" ("it is therefore recommended") is mistakenly
> included.
> To correct the mistake, just remove the word.
> Keep up your awesomeness!
>
I'm not sure this is a mistake. The "therefore" refers to the statement in
the previous sentence, explaining *why* it is recommended.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Installation instructions vs binaries
It's kind of strange that if you start your PostgreSQL journey by reading our instructions, you get nothing useful about installing PostgreSQL from binary packages other than "go ask somebody else about it". Yet we have pretty good step by step instructions on our *website* for it. Attached patch adds a chapter to the docs about installing from binaries, and refers those users to the website download instructions (and updates the Windows instructions to include an actual link to the website). It also adds mention of it in a few other places - -there are probably more that could use some help with that in the future. But I've seen a lot of people get confused by our documentation assuming everything is from source when it comes to initdb and pg_ctl that I think it's worth specially mentioning it there. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/> commit a8321c6fff84c2a6be887b824ac090c49f724f55 Author: Magnus Hagander Date: Wed Jul 15 13:12:28 2020 +0200 Expand installation documentation to cover binary installations diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml index 64b5da0070..463bdfd29c 100644 --- a/doc/src/sgml/filelist.sgml +++ b/doc/src/sgml/filelist.sgml @@ -36,6 +36,7 @@ + diff --git a/doc/src/sgml/install-binaries.sgml b/doc/src/sgml/install-binaries.sgml new file mode 100644 index 00..36405e74cc --- /dev/null +++ b/doc/src/sgml/install-binaries.sgml @@ -0,0 +1,24 @@ + + + Installation from Binaries + + + installation + binaries + + + + PostgreSQL is available in the form of binary + packages for most common operating systems today. When available, this is + the recommended way to install PostgreSQL for users of the system. Building + from source (see ) is only recommended for + people developing PostgreSQL or extensions. + + + + For an updated list of platforms providing binary packages, please visit + the Download section on the PostgreSQL website at + https://www.postgresql.org/download/";> and follow the + instructions for the specific platform. + + diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml index e2b8a4de57..587707b79b 100644 --- a/doc/src/sgml/install-windows.sgml +++ b/doc/src/sgml/install-windows.sgml @@ -11,7 +11,8 @@ It is recommended that most users download the binary distribution for Windows, available as a graphical installer package - from the PostgreSQL website. Building from source + from the PostgreSQL website at + https://www.postgresql.org/download/";>. Building from source is only intended for people developing PostgreSQL or extensions. diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml index 552303e211..ce9bdb1297 100644 --- a/doc/src/sgml/installation.sgml +++ b/doc/src/sgml/installation.sgml @@ -21,7 +21,7 @@ documentation. See standalone-profile.xsl for details. PostgreSQL using the source code distribution. If you are installing a pre-packaged distribution, such as an RPM or Debian package, ignore this chapter - and read the packager's instructions instead. + and see instead. diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml index c41ce9499b..730d5fdc34 100644 --- a/doc/src/sgml/postgres.sgml +++ b/doc/src/sgml/postgres.sgml @@ -154,6 +154,7 @@ break is not needed in a wider output rendering. + &installbin; &installation; &installw; &runtime; diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index 937bb2e8ac..b1b06ed689 100644 --- a/doc/src/sgml/runtime.sgml +++ b/doc/src/sgml/runtime.sgml @@ -26,6 +26,11 @@ binaries. + + When PostgreSQL is installed using binary packages, the user account is + normally created automatically by the package system. + + To add a Unix user account to your system, look for a command useradd or adduser. The user @@ -85,6 +90,14 @@ described in the previous section. + + +When PostgreSQL is installed using binary packages, the initialization +process may be automatic or look slightly different. Refer to the +documentation for these packages for more information. + + + As an alternative to the -D option, you can set @@ -305,6 +318,15 @@ postgres$ initdb -D /usr/local/pgsql/data Starting the Database Server + + +When PostgreSQL is installed using binary packages, starting and stopping +of the system is normally integrated with the service management on the +platform. Refer to the documentation for the documentation for these +packages and the platform for more information. + + + Before anyone can access the database, you must start the database server. The database server program is called
Re: "Direct download" button is broken on www.postgresql.org/download/linux/redhat/
On Fri, Jul 3, 2020 at 3:45 PM Andrey Lizenko wrote: > https://yum.postgresql.org/rpmchart.php returns 404 > > Hi! Thanks for the report -- I've fixed, and also put a redirect in for the old address in case somebody still had it. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: This is not true or at the very least confusing
On Fri, May 8, 2020 at 7:50 PM Dave Cramer wrote: > https://www.postgresql.org/docs/current/backup-file.html says > "The database server *must* be shut down in order to get a usable backup." > > Note: must is in italics. > > Then we have section 25.3.3.1. Making A Non-Exclusive Low-Level Backup > which contradicts this statement with "Perform the backup, using any > convenient file-system-backup tool such as tar or cpio (not pg_dump or > pg_dumpall). It is neither necessary nor desirable to stop normal > operation of the database while you do this." > > While I understand this is a complex topic. I think at the very least we > can refer to section 25.3.3.1 in section 25.2. I also think that the > discussion about frozen snapshots is ill advised. If I were doing it I > would use pg_start_backup before using any file system snapshot. > > Another thing we've talked about on this topic before (but never got around to doing all the way) is to re-order things so that the current 25.3 chapter comes before 25.2. And making sure we put the simple yet correct solutions like pg_basebackup first, and put complicated ones later. And we should really chance the title of what's now 25.2 to explicitly be called "offline file system backups" as well. //Magnus
Re: Direct links to edit documentation
On Tue, May 5, 2020 at 4:49 PM Bruce Momjian wrote: > On Mon, May 4, 2020 at 07:06:55PM +0200, Magnus Hagander wrote: > > I see how that can be pretty useful for something that's as simple as > asciidoc. > > But I wonder how useful it would be for our docbook documentation. > > > > There'd be no preview (which there i sin the elastic), and we know how > > difficult it can be to get the tags right without running test builds > even for > > those that are used to working in the system. > > > > Though if what we're considering are basically drive-by typo fixes and > such, > > those would probably work in a scenario like that, since you're unlikely > to > > need a preview or break a build. > > > > Another complication would be that we don't have a 1-1 mapping between > source > > files and output URLs. So you'd have to find some way to track it back > to the > > exactly right portion of the source file. This would probably be > possible if we > > were to do it as a feature on our own site (and not just a > > source-edit-on-github-style), but it would probably ont be a trivial > piece of > > work. Question is if the benefit would outweigh the cost, compared to > just > > receiving comments and "manually patching them in". > > All I can say is that most emails we get about the docs using the form > are just complaints, and we have to write some suggested text and get > approaval from the reporter that the text is clear. We don't get many > acutal _suggestions_. > Agreed. I think the argument made is that if we had direct editing, maybe we'd get more actual suggestions vs just reports/complaints. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Direct links to edit documentation
I see how that can be pretty useful for something that's as simple as asciidoc. But I wonder how useful it would be for our docbook documentation. There'd be no preview (which there i sin the elastic), and we know how difficult it can be to get the tags right without running test builds even for those that are used to working in the system. Though if what we're considering are basically drive-by typo fixes and such, those would probably work in a scenario like that, since you're unlikely to need a preview or break a build. Another complication would be that we don't have a 1-1 mapping between source files and output URLs. So you'd have to find some way to track it back to the exactly right portion of the source file. This would probably be possible if we were to do it as a feature on our own site (and not just a source-edit-on-github-style), but it would probably ont be a trivial piece of work. Question is if the benefit would outweigh the cost, compared to just receiving comments and "manually patching them in". //Magnus On Wed, Apr 29, 2020 at 11:39 PM Yuri Astrakhan wrote: > ElasticSearch also uses AsciiDoc with the "edit_me" module that generates > those. Code - > https://github.com/elastic/docs/blob/master/resources/asciidoctor/lib/edit_me/extension.rb > > It results in a semi-transparent "edit me" button at the top to the right > of the page title, e.g. > https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-geotilegrid-aggregation.html > > On Wed, Apr 29, 2020 at 1:27 PM Bruce Momjian wrote: > >> On Wed, Apr 29, 2020 at 04:36:37PM +, PG Doc comments form wrote: >> > The following documentation comment has been logged on the website: >> > >> > Page: https://www.postgresql.org/docs/12/runtime-config-wal.html >> > Description: >> > >> > Would it be possible to add "edit this page" links to every PostgreSQL >> doc >> > page, pointing to the docs git repo, ideally on a site that allows >> > on-the-site editing without locally cloning i.e. github? This will >> make it >> > far easier to contribute tiny changes like adding more links in the >> text. >> > For example, https://www.postgresql.org/docs/12/runtime-config-wal.html >> has >> > a lot of useful information, but many setting keywords are not links, >> making >> > it harder to find. Commenting on that page that a link is missing seems >> > silly, whereas if there was an edit button, users could have submitted >> their >> > edits directly. >> >> Wow, that sounds like a nice idea, but I have no idea how to do that. >> >> -- >> Bruce Momjian https://momjian.us >> EnterpriseDB https://enterprisedb.com >> >> + As you are, so once was I. As I am, so you will be. + >> + Ancient Roman grave inscription + >> >
Re: Documentation: 21.5. Default Roles
On Tue, Apr 28, 2020 at 8:20 PM Stephen Frost wrote: > Greetings, > > * Magnus Hagander (mag...@hagander.net) wrote: > > On Sat, Apr 25, 2020 at 1:38 AM Jonathan S. Katz > > wrote: > > > > > On 4/9/20 11:45 PM, Bruce Momjian wrote: > > > > On Thu, Apr 9, 2020 at 08:47:56PM -0400, Jonathan Katz wrote: > > > >> On 4/9/20 4:57 PM, Bruce Momjian wrote: > > > >>> Jonathan, Stephen, with the minor release done, can we focus on > adding > > > >>> the URL redirect and completing the patch to rename this feature > in the > > > >>> docs? Thanks. > > > >> > > > >> Yes, I have a prototype for this ready, which I had scrambled > together > > > >> before the release. I am happy to make it committable in the coming > > > days. > > > > > > > > Thanks. Once that is done Stephen can apply my patch with his > > > > additions. > > > > > > Please see attached patch for pgweb that allows for the documentation > to > > > be redirected from a page that is removed to a newer page. The way it > > > works: > > > > > > - Checks to see if a page is found. If it is, great! > > > - Now if a page 404s, we first check to see if there is a forwarding > > > address, i.e. the new page. If it is, we issue a 301 (permanent > redirecTt). > > > - If it's still not found, we abort. > > > > > > I believe this gives us the desired behavior. > > > > > > Thoughts on the patch? > > > > Looks good to me. Go for it. > > What's the plan for how to maintain it going forward? Just email -docs > and ask someone to perform the update whenever a release is going out..? > Or do we have some kind of better process in mind? > > GIven how seldom this happens, I think that's perfectly fine. Same as we already do with the page aliases. //Magnus
Re: Documentation: 21.5. Default Roles
On Sat, Apr 25, 2020 at 1:38 AM Jonathan S. Katz wrote: > On 4/9/20 11:45 PM, Bruce Momjian wrote: > > On Thu, Apr 9, 2020 at 08:47:56PM -0400, Jonathan Katz wrote: > >> On 4/9/20 4:57 PM, Bruce Momjian wrote: > >>> Jonathan, Stephen, with the minor release done, can we focus on adding > >>> the URL redirect and completing the patch to rename this feature in the > >>> docs? Thanks. > >> > >> Yes, I have a prototype for this ready, which I had scrambled together > >> before the release. I am happy to make it committable in the coming > days. > > > > Thanks. Once that is done Stephen can apply my patch with his > > additions. > > Please see attached patch for pgweb that allows for the documentation to > be redirected from a page that is removed to a newer page. The way it > works: > > - Checks to see if a page is found. If it is, great! > - Now if a page 404s, we first check to see if there is a forwarding > address, i.e. the new page. If it is, we issue a 301 (permanent redirecTt). > - If it's still not found, we abort. > > I believe this gives us the desired behavior. > > Thoughts on the patch? > Looks good to me. Go for it. //Magnus
Re: pg_stat_statements showing passwords while create or alter users.
On Fri, Apr 17, 2020 at 8:50 AM PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/bug-reporting.html > Description: > > pg_stat_statements is recording passwords also, is there any way to avoid > the logging of passwords without droping extension package. > testdb=> create user test1 with password 'test123'; > CREATE ROLE > testdb=> create user test2 with encrypted password 'test123'; > CREATE ROLE > test=> select query from pg_stat_statements where query like '%test%'; >query > --- > create user test1 with encrypted password 'test123' > create user test2 with password 'test123' > > > edbss=> drop extension pg_stat_statements; > DROP EXTENSION > This is documented behaviour and not a bug. The documentation for create user/create role says: "Caution must be exercised when specifying an unencrypted password with this command. The password will be transmitted to the server in cleartext, and it might also be logged in the client's command history or the server log. The command createuser, however, transmits the password encrypted. Also, psql contains a command \password that can be used to safely change the password later." So yes, per that page, use createuser, use \password in psql, or you can also use the PQencryptPasswordConn() API function in libpq if you are building an application and not just running it one-off. You can of course also use pg_stat_statements_reset() to clear it out of the existing history but that doesn't prevent it from being stored there for a short while. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Documentation: 21.5. Default Roles
On Mon, Feb 3, 2020 at 9:59 PM Jonathan S. Katz wrote: > > On 2/3/20 3:42 PM, Bruce Momjian wrote: > > On Thu, Jan 23, 2020 at 07:12:08PM -0500, R Ransbottom wrote: > >> On Mon, Jan 20, 2020 at 12:23:48PM +0900, Ian Barwick wrote: > >>> On 2020/01/19 12:56, R Ransbottom wrote: > >> > >>>> I would hope to find correct documentation somewhere--that somewhere > >> > >>> Indeed, however it's important that the PostgreSQL documentation remains > >>> stable for released versions. > >> > >>> As-is, the current patch set would result in the term "default role(s)" > >>> disappearing from the documentation in the next minor release, which is > >>> bound to cause confusion for anyone searching the documentation for the > >>> term they're familiar with (unless they happen to be reading this thread > >>> or following the git commit log). Cue cries of "OMG Postgres removed a > >>> feature in a minor release!!!?!!". > >> > >>> And as Stephen mentions, it will break a lot of secondary documentation - > >>> not just blogs but things like internal training materials etc. > >> > >>> If this change is made (which I'm personally not against), then it should > >>> be > >>> only from PostgreSQL 13. For 9.6 ~ 12, IMHO it would be better to tweak > >>> the > >>> existing documentation to somehow mention that "default roles" should be > >>> thought of as "prefined roles", and note they will be called this from > >>> Pg13. > >> > >> Ian, agreed modulo 13. > >> > >> The current section(s) could forward readers to a revised section. The > >> DEFAULT_ROLE_* stuff could carry two names to allow a comprehensive fix > >> in 12.X. That could allow the deprecation and misinformation to end one > >> EoL sooner. > > > > With minor releases coming next week, and no movement on doing web > > redirects, and no clarity on what this is missing even in master, I will > > revert this patch in all branches soon. I think everyone agrees the new > > documentation title is better, but we don't want to break things or add > > inconsistency to do it. > > Sorry, I missed the original comment on the "web redirects" Same here. It was buried a little too deep in an existing therad. > > So, if there was something done to redirect people from specific > deprecated documentation pages historically, it was before my time. Most > of the redirects have been as general purposes ones (e.g. /docs/12), the > rules we put in for getting rid of "static", and the release notes, > which still receives some negative feedback towards it for different > reasons (though I think overall the effort was well-received). Anyway, > if we had a redirect in place, I'd want us to do it well. We have something close to it in commit 496416ceda9c1015d9e7a6ef4b4fb18dae8a8d4e. But that doesn't actually generate redirects when requests are coming in from the outside -- it just makes sure our *internal* links can survive the rename of a file between branches. So it may not be exactly what's being looked for here, but it might be a starting point. Probably the same underlying mapping table could be used, but I haven't investigated that closely enough to say if it's doable at this point, just that it's a starting point. Using this feature to handle the rename of a file *between* major versions, thus leaving the changes in master, should be safe (as long as we add an entry to that table in pgweb). As for back branches, I think we have to say that it's too close to the minor release to safely have something done in pgweb before then. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Re: Typo
On Wed, Jan 29, 2020 at 9:55 AM PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/11/libpq-ssl.html > Description: > > On page https://www.postgresql.org/docs/11/libpq-ssl.html in phrase "if no > Subject Alternative Name of type dNSName is present." dNSName should be > DNSName No, that documentation is actually correct. The field name is actually dNSName -- see https://tools.ietf.org/html/rfc5280 which defines it. It's somewhat ridiculous, but you have the same thing with iPAdress for example. I guess because the first letter has to be lowercase. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Re: Suggestion on Document for Version 12 Section 40.3
On Thu, Jan 9, 2020 at 10:42 AM Daniel Gustafsson wrote: > > > On 9 Jan 2020, at 09:28, PG Doc comments form > > wrote: > > > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/12/rules-materializedviews.html > > Description: > > > > Hello all, > > > > > > I'm reading Section 40.3, and there is an example (the third square by > > reverse order): > > > > > > SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; > > > > word > > --- > > cater > > caterpillar > > Caterpillar > > caterpillars > > caterpillar's > > Caterpillar's > > caterer > > caterer's > > caters > > catered > > (10 rows) > > > > > > As shown here https://www.postgresql.org/docs/current/pgtrgm.html, the > > operator `<->` is in an additional module. Without the context, the reader > > will need searching to help understand the meaning. It would be better if > > further reference is given. > > I agree that this could lead to unnecessary confusion for readers, and since > we > are already mentioning that file_fdw is used it seems reasonable to also > mention pg_trgm. A suggested patch is attached. Seems correct. Pushed, thanks! //Magnus
Re: Link to "Upgrading a PostgreSQL Cluster" in Release Notes
On Fri, Jan 3, 2020 at 9:57 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-12-30 00:03, Vik Fearing wrote: > > Following a complaint on IRC about the dearth of information on how to > > migrate to a new major version in the release notes, the attached > > trivial patch was determined to be sufficient for the OP. > > > > This patch applies to REL_12_STABLE. I don't know how far it should be > > backpatched (the OP was trying to upgrade to v10), and I didn't see any > > place to put it for 13 and future versions. > > I think this change is sensible. But to what extent do we want to edit > around in old release notes? Should we just keep it for PG13? > I think it makes sense to backpatch it. Lots of people still upgrade to at least 12 and 11, and that's a likely place for them to start reading. And if we're already covering 12 and 11, it is probably no big extra effort to do other supported branches as well. I think we should also extend the blurb in the release notes to mention > the option of using logical replication to upgrade. Otherwise, if you > follow the link you propose, then one might think that logical > replication upgrading is not applicable since only pg_dump and > pg_upgrade were mentioned in the place the link came from. > > +1. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: I suggest improving install steps for CentOS 8
On Mon, Dec 9, 2019 at 6:38 PM Devrim Gündüz wrote: > > Hi, > > On Mon, 2019-12-09 at 13:17 +0100, Magnus Hagander wrote: > > > > What is the normal time to do this, in the sequence. After the repository > > rpm is installed but before client packages? > > Right. > > I have pushed an update for this to the site. //Magnus
Re: I suggest improving install steps for CentOS 8
On Mon, Dec 9, 2019 at 1:11 PM Devrim Gündüz wrote: > > Hi, > > On Thu, 2019-11-14 at 10:29 +0100, Daniel Gustafsson wrote: > > Adding -www as this isn't a documentation issue but a website issue. > > Adding Magnus :-) > > Seriously speaking, for RHEL 8, we need to add > > dnf -qy module disable postgresql > > command. Magnus, can you patch this when you can? > Yeah, it seems like it would be better to add this as part of the instructions rather than as a note on the side. What is the normal time to do this, in the sequence. After the repository rpm is installed but before client packages? And is there any case you'd want to add the pg repositories but *not* do this? I assume not? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Description of Authentication Methods Supported for Map is Misleading
On Fri, Dec 6, 2019 at 10:13 AM PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/auth-pg-hba-conf.html > Description: > > "This option is supported for all authentication methods that receive > external user names." > > More properly, the authentication methods supported are: ident, peer, > gassapi, sspi, and cert. > > LDAP is not supported and attempting to use map with LDAP provides the > following error: > 'authentication option ""map"" is only valid for authentication methods > ident, peer, gssapi, sspi, and cert' > This is correct. LDAP authentication does not receive external usernames. It uses an external service to validate the password, but it gets the username from the client. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Odd markup in SSL mode table
On Wed, Nov 20, 2019 at 2:58 PM Daniel Gustafsson wrote: > In the SSL mode table (33.1), one of the "MITM Protection" values is set > using > while seemingly being normal text. It has been like this since > added > in af2cf3be03f284aa12a07bce2b95d4a2768b290f, but I can't figure out why, > and it > makes it look odd IMO. > > Any reason not to apply the attached and remote the tags to make > the > row in question formatted like the other rows in the table? > No, that looks like a copy/paste error that has survived for 10 years. Will apply. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: A4 pdf points to 11.5 instead of 11.6
On Tue, Nov 19, 2019 at 9:34 AM Daniel Gustafsson wrote: > > On 19 Nov 2019, at 09:09, William Sescu (Suva) > wrote: > > > If I download the A4 pdf of the version 11, it says 11.5 documentation. > > > > https://www.postgresql.org/docs/manuals/ > > > > However, it should contain the 11.6 documentation. Shouldn’t it? > > It indeed should. Looking at the other versions, none of the PDFs have > been > rebuilt for the latest minor releases. > > Bringing this to -www since it's likely to be an infrastructure issue > rather > than a docs issue. > They were rebuilt and pushed, but it seems the job that deployed them failed and that whomever ran it didn't notice the error :/ I've force-deployed it now, so the new PDFs will appear as soon as the caches have expired. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: 20.3. Authentication Methods for PostgreSQL 11 not present
On Thu, Oct 31, 2019 at 7:40 PM PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/11/auth-methods.html > Description: > > In section 20.3 of PostgreSQL 11, the documentation is lacking the same > amount of content as in section 20.3 of other versions of PostgreSQL. All > information about LDAP authentication seems to be missing from this page. > The page has been split into separate section. The LDAP information is at https://www.postgresql.org/docs/11/auth-ldap.html. (You get there by clicking "up" on the page you mentioned, and then picking it in the index) -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: I'm surprised to see the word master here
On Wed, Oct 2, 2019 at 3:10 PM Jonathan S. Katz wrote: > On 10/2/19 7:39 AM, Chris Travers wrote: > > > > > > On Wed, Oct 2, 2019 at 12:57 PM Erikjan Rijkers > <mailto:e...@xs4all.nl>> wrote: > > > > On 2019-10-02 12:46, Peter Eisentraut wrote: > > > On 2019-10-02 10:21, Magnus Hagander wrote: > > >> Exactly. Both might be accurate, but one comes with a lot less > > >> baggage. > > >> > > >> I support a search and replace. > > >> > > >> I think it'll take a bit more than just a simple "sed script to > > >> replace", if that's what you mean. But probably not all that much > -- > > >> but > > >> there can certainly be cases where nearby langaugae also has to be > > >> changed to make it work properly. But I have a hard time seeing > it as > > >> being a *huge* undertaking. > > > > > > I find this proposal to be dubious and unsubstantiated. Do we > need to > > > get rid of "multimaster", "postmaster"? > > > > > > > IMHO, hat would seem a bad idea. Let's not take the politicising too > > far. > > > > I would say leave it at abolishing 'slave' (as we have already done). > > > > > > But that raises an important point, which is that if we remove master > > entirely from the replication lexicon, then I don't see how multi-master > > makes sense. If consistency is a goal, postmaster still works but there > > is no alternative to multi-master in common usage. > > At various events and tradeshows that include representation from other > database systems, the terminology that I hear is "active-active" -- this > is not one-off, but from a lot of people. This is also a common term for > the major proprietary systems as well. I hear it much more commonly than > "multi-master" even. > That has the tiny problem of not being correct though. A classic primary/standby cluster is *also* active/active. It used to be very common to have active/passive clusters -- these were the typical shared-disk-mounted-on-one-node-at-a-time style clusters. This indicates that the standby node isn't available *at all* until after a fail/switchover. So pretty much anything based on our streaming replication today is active/active.. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: I'm surprised to see the word master here
> On Wed, Oct 2, 2019 at 8:59 AM Selena Deckelmann wrote: Hi! > Whoa! That was a long time ago. Welcome back! :) Hi! On Wed, Oct 2, 2019 at 8:06 AM Stephen Frost wrote: > >> >> >> I know that I tend towards primary/replica when discussing physical >> replication, and we do that quite a bit in the documentation (consider >> https://www.postgresql.org/docs/11/warm-standby.html where we seem to be >> pretty confused about if we want to talk about the system as a 'primary' >> or as a 'master'- but *clearly* primary is winning the war there). > > +1 for consistency. And since we're already in an inconsistent state, it seems only logical in which direction to change to make it consistent. It has the advantage of being accurate and with significantly less social > baggage. > Exactly. Both might be accurate, but one comes with a lot less baggage. I support a search and replace. > I think it'll take a bit more than just a simple "sed script to replace", if that's what you mean. But probably not all that much -- but there can certainly be cases where nearby langaugae also has to be changed to make it work properly. But I have a hard time seeing it as being a *huge* undertaking. //Magnus
Re: Fix contributor name-related inconsistencies in release-12.sgml
On Wed, Sep 25, 2019, 00:52 Tom Lane wrote: > Peter Eisentraut writes: > > On 2019-09-23 13:08, Alexander Lakhin wrote: > >> While translating Release Notes for version 12 I found some > >> inconsistencies with contributor names. > > > We had discussed this in previous years and resolved that we use the > > forms that these individuals use when posting to these mailing lists, in > > whichever order they prefer. So as far as I'm concerned, the forms > > listed in the release notes for PG10 and PG11 are canonical and should > > continue to be used. > > I have no strong feelings either way, so feel free to undo whatever > you think should be undone. > > I have noted that many of our Japanese contributors show a different name > order in their From: line than in their signature/footer, so it's not > entirely clear which preference they're expressing. > I would say use the one in the signature in those cases. My guess would be that that part is under control of the individual, but the from field is in control of the HR department or whomever controls the name order in the catalogs of their big company. It's fairly common here, for example, to have "lastname, first" in the from, but nobody would use that in a scenario like this. The reason typically being wanting "phone book sorting" in the company wide address book, which does sort on lastname. As an employee people can typically control the name order in their signature, but not the address book. The situation in Asia may of course be very different, as it often is, but I think the general rule of who controls the order where still applies. /Magnus
Re: initdb recommendations
On Mon, Apr 8, 2019 at 2:41 PM Jonathan S. Katz wrote: > On 4/8/19 8:25 AM, Peter Eisentraut wrote: > > On 2019-04-05 18:11, Jonathan S. Katz wrote: > >> + > >> + We recommend using the -W, > --pwprompt, > >> + or --pwfile flags to assign a password to the > database > >> + superuser, and to override the pg_hba.conf > default > >> + generation using -auth-local peer for local > connections, > >> + and -auth-host scram-sha-256 for remote > connections. See > >> + for more information on > client > >> + authentication methods. > >> + > > > > As discussed on hackers, we are not ready to support scram-sha-256 out > > of the box. So this advice, or any similar advice elsewhere, would need > > to recommend "md5" as the setting --- which would probably be > embarrassing. > > Well, it's less embarrassing than trust, and we currently state: > Yes. Much less. "Also, specify -A md5 or -A password so that the default trust > authentication mode is not used"[1] > > We could also modify it to say : > > "and -auth-host scram-sha-256 for remote connections if > your client supports it, otherwise -auth-host md5" > That would be the best from a correctness, but if of course also makes things sound more complicated. I'm not sure where the right balance is there. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: initdb recommendations
On Fri, Apr 5, 2019 at 10:58 PM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-04-05 18:11, Jonathan S. Katz wrote: > > (There could be an additional discussion about whether or not we want to > > change the default behavior for initdb, but I would suggest that a safe > > starting point would be to ensure we call this out) > > I think we should just change the defaults. There is a risk of warning > fatigue. initdb does warn about this, so anyone who cared could have > gotten the information. > I've been suggesting that for years, so definite strong +1 for doing that. If it's something that annoys backend developers who initdb very often, I suggest we add an environment variable to override it. But I'm not sure that's really necessary -- creating a shell alias or similar is easy to do, and most have probably already done so for other reasons. That said, I think it would make sense to *also* have a warning. And in particular, we should strongly consider backpatching a warning. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Clarification to pg_upgrade docs on reverting to old cluster
On Thu, Apr 4, 2019 at 11:14 PM Daniel Gustafsson wrote: > 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. > Let's have two non-english natives discuss it :), 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? 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? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Supported versions missing at the top of the page
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 > <https://www.postgresql.org/docs/current/progress-reporting.html> (11 > <https://www.postgresql.org/docs/11/progress-reporting.html>) / 10 > <https://www.postgresql.org/docs/10/progress-reporting.html> / 9.6 > <https://www.postgresql.org/docs/9.6/progress-reporting.html> > > > That is because this page did not exist before version 9.6. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: First SVG graphic
On Thu, Mar 28, 2019 at 9:59 AM Magnus Hagander wrote: > > > On Thu, Mar 28, 2019 at 8:50 AM Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: > >> On 2019-03-28 01:50, Tom Lane wrote: >> > Peter Eisentraut writes: >> >> This has been committed. The SVG images are committed as well, so no >> >> new tools are required. >> > >> > Buildfarm member alabio seems less than pleased. >> >> See >> < >> https://askubuntu.com/questions/695560/assistive-technology-not-found-awterror >> > >> for how to fix that build issue. >> > > Ugh. If I understand it right, that's something that will happen to > anybody who tries to build the docs on a headless server, which is not > exactly uncommon :/ > > Can we find a way to override it in the command? Or if not, we should > probably at least document it in our docs? > > I have done this on alabio now, let's see if it recovers. > > FYI, it did recover. Per above, I think this is something we should document. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: First SVG graphic
On Thu, Mar 28, 2019 at 8:50 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-03-28 01:50, Tom Lane wrote: > > Peter Eisentraut writes: > >> This has been committed. The SVG images are committed as well, so no > >> new tools are required. > > > > Buildfarm member alabio seems less than pleased. > > See > < > https://askubuntu.com/questions/695560/assistive-technology-not-found-awterror > > > for how to fix that build issue. > Ugh. If I understand it right, that's something that will happen to anybody who tries to build the docs on a headless server, which is not exactly uncommon :/ Can we find a way to override it in the command? Or if not, we should probably at least document it in our docs? I have done this on alabio now, let's see if it recovers. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Typo in ECPG documentation
On Tue, Mar 26, 2019 at 1:21 PM Daniel Gustafsson wrote: > Attached patch fixes a small typo in the ECPG documentation that I happened > to spot: s/DELARE/DECLARE/. > > Applied, thanks. //Magnus
Bug reporting guidelines order of instructions
Per the docs comment today, I will remove the notes about majordomo at https://www.postgresql.org/docs/current/bug-reporting.html. However, this one also suggests email to the pgsql-bugs report as the primary choice "and you can also use the bugs form. Do we perhaps want to change the order of these and suggest the web form as the primary method, since that hands out bug ids? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: majord...@postgresql.org: unknown address
On Thu, Jan 17, 2019 at 11:15 AM PG Doc comments form < nore...@postgresql.org> wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/bug-reporting.html > Description: > > Hi, > > https://www.postgresql.org/docs/10/bug-reporting.html says "For more > information send mail to with the single word > help in the body of the message.". However sending email to this address > fails: > > : host magus.postgresql.org[87.238.57.229] said: > 550 > unknown address (in reply to RCPT TO command) > > Hi! That is indeed incorrect. Please go to https://lists.postgresql.org/ for instructions on how to subscribe to it. I will make sure the instructions are updated in the documentation. Thanks for the report! //Magnus
Re: tickling the lesser contributor's withering ego
On Fri, Dec 21, 2018 at 4:17 PM Alvaro Herrera wrote: > On 2018-Dec-21, Tom Lane wrote: > > > Alvaro Herrera writes: > > > I propose the following patch, which will make those links stable -- > > > then we can add the following links to the contributors page: > > > > https://www.postgresql/org/docs/10/release-10.html#RELEASE-10-ACKNOWLEDGEMENTS > > > > https://www.postgresql/org/docs/11/release-11.html#RELEASE-11-ACKNOWLEDGEMENTS > > > > Seems reasonable, but note the lag time --- unless somebody does > > something out of the ordinary, those pages won't actually have > > such tags till after the February minor releases. > > Good point. That seems acceptable to me. > Good. While it *can* be worked around, it's a PITA and it risks getting overwritten by other things, since the normal docs loads are based off release tarballs. We can make them off a snapshot tarball, but it's a pain :) Oh, and +1 for stable links like that in general. That would be one good step. Not having considered what to do with, but it could also be interesting to teach the loader to read the structured data out of the XML file and store it in one of these weird things called a "database". That could be used for things like matching on the contributors list and add a little per-version badge to which versions they are known to contribute etc. That would require us to be quite consistent in the naming of people, and also not to have duplicates though, but maybe it can be valuable? Actually, do we have a policy for handling duplicates in the docs there? Since we only keep names there and not email or similar? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: First SVG graphic
On Wed, Nov 28, 2018 at 8:53 PM Alvaro Herrera wrote: > On 2018-Nov-28, Bruce Momjian wrote: > > > On Wed, Nov 28, 2018 at 11:46:33AM -0800, Andres Freund wrote: > > > Hi, > > > > > > On 2018-11-28 18:34:26 +0100, Jürgen Purtz wrote: > > > > After one week no response at all? Neither positive nor negative. It > seems > > > > that the community has little interest in the SVG issue. Or in my > > > > suggestion? > > > > > > I'd suggest describing your proposed workflow in sgml, not a pdf file. > > > > Well, there were a number of images in the PDF that would be harder to > > do in SGML. > > I think the point is how do you integrate the images from the SVG source > into the documentation output. Presumably that won't be PDF, for > example the HTML output will not use a PDF as an image embedded in the > page. It probably works ok for the PDF output (of the whole > documentation) to use the PDF of the image ... I suppose the HTML output > will need a PNG or such. > > If the source is SVG, why not just use SVG? SVG support in browsers has to be pushing 10 years now, shouldn't be a problem at all... And SVG can be embedded in the HTML itself (whether that would work in this particular case I don't know, but in theory it can) -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: typo
On Mon, Nov 26, 2018 at 8:42 AM Michael Paquier wrote: > On Mon, Nov 26, 2018 at 08:17:06AM +0100, Vik Fearing wrote: > > On 26/11/2018 08:03, Magnus Hagander wrote: > >> Are you sure that's right? To me the original wording of that sentence > >> seems to convey the message properly, and the update done does not? > > > > Yeah, I just found this on the committers list and I disagree with the > > change as well. > > [... checking around ...] > Hm. I have read the sentence and the surroundings a couple of times > before doing anything, and using an adverb looked clearer than the > adjective. Is an adjective more appropriate than an adverb here because > it insists more on the fact that each row is involved? Just trying to > grab the difference. > If the current text is unclear to people we should definitely fix it -- just to the right thing. Maybe say something like "keep inline in the regular table rows" instead? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: typo
On Mon, Nov 26, 2018, 07:56 Michael Paquier On Mon, Nov 26, 2018 at 12:47:51AM +, PG Doc comments form wrote: > > Correction: A table that has columns with potentially large entries will > > have an associated TOAST table, which is used for out-of-line storage of > > field values that are too large to keep in the table rows "PROPERLY". > > Thanks, committed. I have fixed the docs to reflect your suggestion. > - > Are you sure that's right? To me the original wording of that sentence seems to convey the message properly, and the update done does not? /Magnus >
Re: Missing whitespace in pg_dump docs
On Fri, Oct 26, 2018 at 3:27 PM Daniel Gustafsson wrote: > The attached diff adds what seems to be a missing whitespace in the > discussion > on dump formats. > Pushed, thanks. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Release note trimming: another modest proposal
On Mon, Aug 6, 2018 at 11:17 PM, Jonathan S. Katz wrote: > > > On Aug 6, 2018, at 3:37 PM, Tom Lane wrote: > > > > "Jonathan S. Katz" writes: > >>> On Aug 6, 2018, at 3:27 PM, Tom Lane wrote: > >>> Actually, a concrete reason why that might not be good is that it > results > >>> in having a single point of failure: once we remove branch N's relnotes > >>> from the active branches, the only copy of that data is the one in the > >>> archive table the docload script is filling. Given, say, a bug in the > >>> docload script that causes it to overwrite the wrong table entries, > >>> can we recover? > > > >> Well, the release notes are still in the git history as well as the > tarballs. > >> One could always pull an older tarball of PostgreSQL with the full > >> release.sgml and load from there. > > > > True ... as long as those older tarballs represent data that our current > > workflow can process. For instance, if we did another documentation > > format change (from XML to something else), the older tarballs would > > perhaps no longer be useful for this purpose. > > > > On the other hand, it's hard to believe that we'd make such a conversion > > without tools to help. So probably if the situation came up, we could > > cobble together something that would allow ingesting the old format. > > Attached is a (rough) working copy of the patch to pgweb. It can: > > - Extract the release notes from the docload and puts them into their > own table > Not a huge fan of keeping a separate copy of them. I think we can find a way to make it work off the current data, which would simplify the process a bit I think. > - Display the release notes via pgweb akin to earlier screenshots > A thought on this. Do we actually need a separate copy of the release notes at all? What I mean is: We have all the old branch tip release notes already on the site, in the docs for that particular version. Wouldn't we get pretty far by just creating a separate *index*, that then links directly to those release notes? One advantage of that would be that we'd get away from that link rewriting that you did in your patch -- because the docs will actually live at their "natural" location. The downside would be that they'd end up under "docs" in the navigation breadcrumbs, rather than under "release notes". But is that really a problem? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Release note trimming: another modest proposal
On Fri, Aug 10, 2018 at 1:38 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 06/08/2018 00:57, Tom Lane wrote: > > Anyway, I'd like to propose a compromise position that I don't think > > has been discussed before: let's drop release notes for branches > > that were already EOL when a given branch was released. So for > > example, 9.3 and before would go away from v12, due out next year. > > Working backwards, we'd drop 9.1 and before from v10, giving the 15% > > savings in page count that I showed above. A quick measurement says > > that would also trim the size of the v10 tarball by about 4%, which > > is not a lot maybe but it's noticeable across a lot of downloads. > > Why not go further and just ship the release notes of the current major > version. If you want to look at the release notes of version 11, read > the documentation for version 11. Who reads the documentation of > version 12 to get the release notes of version 11? > +1 for that. At least if we get a generic release notes index up on the website, easy to find. That might also make the process of manually merging release notes back and forth in the release process easier, I assume? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Release note trimming: another modest proposal
On Mon, Aug 6, 2018 at 9:37 PM, Tom Lane wrote: > "Jonathan S. Katz" writes: > >> On Aug 6, 2018, at 3:27 PM, Tom Lane wrote: > >> Actually, a concrete reason why that might not be good is that it > results > >> in having a single point of failure: once we remove branch N's relnotes > >> from the active branches, the only copy of that data is the one in the > >> archive table the docload script is filling. Given, say, a bug in the > >> docload script that causes it to overwrite the wrong table entries, > >> can we recover? > > > Well, the release notes are still in the git history as well as the > tarballs. > > One could always pull an older tarball of PostgreSQL with the full > > release.sgml and load from there. > > True ... as long as those older tarballs represent data that our current > workflow can process. For instance, if we did another documentation > format change (from XML to something else), the older tarballs would > perhaps no longer be useful for this purpose. > > On the other hand, it's hard to believe that we'd make such a conversion > without tools to help. So probably if the situation came up, we could > cobble together something that would allow ingesting the old format. > The current process to load the docs is basically "extract the HTML files from the tarballs". We run this against the tarballs of any "latest minor release". So yes, as long as we are OK with only loading release notes the same way we do docs, which is from tarballs, then I really don't think this part will be a problem, and we don't need to do anything about the old files either. But it's not like we're going to be *editing* old release notes in branches that are out of support. We'll be trimming them out of the master branch, but the master branch is not used to load the old docs, only the developer docs. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: retroactive pg10 relnotes: sequence changes
On Tue, Aug 28, 2018 at 6:34 PM, Alvaro Herrera wrote: > Hello > > A customer of ours was taken by surprise by a change in Postgres 10 on a > trial upgrade from 9.6. They were using sequences from SERIAL columns a > little unorthodoxly, and their stuff stopped working: essentially, they > hacked the default expression so that it'd automatically use negative > numbers when the sequence reached INT_MAX. Since pg10 changed sequences > to stop emitting values at that point, it raised an error rather than > emit the negative numbers. > > (In 9.6 and prior, the sequence would emit values past INT_MAX; it was > the column that raised the error. In pg10 things were changed so that > it is now the sequence that raises the error.) > > My proposal now is to document this issue in the Postgres 10 release > notes. "It's a little late for that!" I hear you say, but keep this in > mind: many users have *not* yet upgraded to 10, and they'll keep doing > it for years to come still. So I disagree that now is too late. We > failed to warn people that already upgraded, but we're still on time to > alert people yet to upgrade. > > I attach both the patch and a screenshot to show how minor the visual > effect of the change is. > > (If people hate this, another option is to make it a separate bullet > point.) > Looks reasonable to me. And I definitely think we should do it -- people will be upgrading to 10 for years to come, so claiming it's too late is definitely not correct. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Dead link to hp docs
On Tue, Jul 3, 2018 at 7:37 AM, Tom Lane wrote: > Alvaro Herrera writes: > > On 2018-Jul-02, Michael Paquier wrote: > >> Here are all the broken links in the source tree: > >> > >> doc/src/sgml/libpq.sgml: > >> Wrong: http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04.html > >> Correct: http://h41379.www4.hpe.com/doc/83final/ba554_90007/ch04.html > >> > >> doc/src/sgml/runtime.sgml: > >> Wrong: http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s02.html > >> Correct: http://h41379.www4.hpe.com/doc/83final/ba554_90007/ > ch04s02.html > > > I think HP break their site on a regular basis. > > Well, more to the point, it's obvious from the very form of these links > that HP don't intend them to be stable externally-referenceable URLs. > I remember being unhappy from the beginning that Bruce would try to link > to them in our docs, and I think we're seeing now that indeed they're > not trustworthy permanent URLs. > > > Maybe we should be > > looking for some more stable source of similar information? > > Exactly. > +. I've been thinking that for a while. And it's not the first time they changed things on us. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Typo in documentation page 6.1 Inserting Data
On Sat, May 26, 2018 at 9:15 PM, PG Doc comments form < nore...@postgresql.org> wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/static/dml-insert.html > Description: > > Typo in documentation page: > https://www.postgresql.org/docs/10/static/dml-insert.html > Typo is the word "considering"; it should be "consider". > > Existing wording: > When inserting a lot of data at the same time, considering using the COPY > command. > > Change to: > When inserting a lot of data at the same time, consider using the COPY > command. > I've applied a fix for this. Thanks for the report! -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Misc typos in documentation
On Tue, Jun 19, 2018 at 9:46 AM, Liudmila Mantrova < l.mantr...@postgrespro.ru> wrote: > Hi, > > Please consider these small patches that fix a couple of typos in > documentation. > > I have split them in two just in case rn-typos.patch conflicts with any > current work on release-11.sgml, which seems to be going on in more than > one thread. I'll appreciate your feedback if it should have been done > differently. Hi! These all look good to me. Thanks, applied! -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Incorrect IPC advice for OpenBSD
On Wed, May 16, 2018 at 10:45 PM, Daniel Gustafsson wrote: > The OpenBSD paragraph in the "Shared Memory and Semaphores” section seems > to > have been slightly incorrect since around 2002. The kern.ipc.shm_use_phys > sysctl setting has never existed in OpenBSD (it is in NetBSD and FreeBSD) > and > SEMMAP is not a kernel configuration option. Further, there is no kernel > config for locking shared memory into RAM so the whole paragraph is best > removed it seems. I believe this is an artifact from FreeBSD and OpenBSD > sharing a paragraph, which was split into separate ones a long time ago. > > The attached patch removes the above mentioned parts (confirmed with an > OpenBSD > developer). This should probably be backpatched to all supported versions > as > it’s been wrong for a long time. > Applied and backpatched. Thanks! -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: authentication methods sections
On Thu, Apr 12, 2018 at 2:37 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > I find that the section authentication methods > <https://www.postgresql.org/docs/devel/static/auth-methods.html> is > becoming harder to read and navigate, because we keep adding > authentication methods and more information about them, and it's all on > one HTML page. I propose to move those sections up one level in the > hierarchy so they end up on separate HTML pages. > +1, that definitely seems like a good idea. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Blanks in the first line before the first word in the code boxes
On Wed, Apr 4, 2018 at 3:21 PM, Jonathan S. Katz wrote: > > On Apr 3, 2018, at 10:55 AM, Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: > > On 4/3/18 09:12, Magnus Hagander wrote: > > I've pushed the fix and reloaded the 10 docs. I have not reloaded > earlier branches yet, but I'd be interested in some people reviewing a > bunch of pages in the 10 docs mainly to see if (1) it fixes all the > cases, and (2) it actually breaks some *other* cases. > > > It looks correct now. > > > +1 > > Did a spot check on known broken pages and chose some others at > random. Viewed the 9.6, 10, and devel versions. 10 and devel both > looked correct, and the 9.6 was broken where expected. > > The only thing I saw (and this may be something to look at the SGML > source) was some blocks that looked overly indented, but it was consistent > across all versions. On > > https://www.postgresql.org/docs/current/static/queries-with.html > > If you search for "WITH RECURSIVE search_graph(id, link, data, depth)” > the expression in the CTE is much more indented than similar CTEs above > it. > > IMV I would not let this stop us from reloading the earlier versions as > that > indentation is consistent across all versions (including 9.6, where it has > the > initial indentation as well). > > I've reloaded docs back to 9.3. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Blanks in the first line before the first word in the code boxes
On Mon, Apr 2, 2018 at 5:59 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 4/1/18 11:55, Magnus Hagander wrote: > > However, why does devel work fine when the others are broken. It's the > > exact same code that's run to load the docs. The *input* to the loader > > must also be different at some point. > > In devel, the raw HTML output looks like > > ... > ALTER FOREIGN TABLE [ IF EXISTS ] [ ONLY ] ... > > (with a line break) > > but before it looks like > > ... ALTER FOREIGN TABLE [ IF EXISTS ] [ ONLY ] ... > > (without a line break). > > So maybe some part of the processing code thinks it should do some kind > of "indentation" here. > > I think I found the problem, and pushed a fix for it. Basically it turns off indentation completely on pre-11 versions., I elected to keep indention on dev because it works there, and it makes debugging any of the formatting a lot easier. I've pushed the fix and reloaded the 10 docs. I have not reloaded earlier branches yet, but I'd be interested in some people reviewing a bunch of pages in the 10 docs mainly to see if (1) it fixes all the cases, and (2) it actually breaks some *other* cases. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Blanks in the first line before the first word in the code boxes
On Thu, Mar 29, 2018 at 3:40 PM, Tom Lane wrote: > Magnus Hagander writes: > > Is it possible that this issue actually showed up around 4-5 February, > but > > just has gone unnoticed since? > > It's been there a few weeks, anyway --- I remember somebody complaining > before this particular thread started. I wouldn't be a bit surprised > if it broke then. > Yeah, it's quite likely that it got broken by the OS upgrade and nobody picked up on it before then. This can probably be because the backbranch documentation is only updated when we make actual releases. However, why does devel work fine when the others are broken. It's the exact same code that's run to load the docs. The *input* to the loader must also be different at some point. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Documentation for varbit is missing size parameter
On Fri, Mar 30, 2018 at 7:34 PM, Bruce Momjian wrote: > On Fri, Mar 30, 2018 at 10:31:07AM -0700, David G. Johnston wrote: > > On Friday, March 30, 2018, Bruce Momjian wrote: > > > > I looked at this patch and thought it was more a stylistic item > rather > > than a correction. Is that right? > > > > > > Looks like a syntax bug fix to me - especially since it is a reference > table. > > Those should be back-patched. > > OK, now backpatched through 9.3. > > Thanks! -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Documentation for varbit is missing size parameter
On Fri, Mar 30, 2018 at 6:26 PM, Bruce Momjian wrote: > On Fri, Mar 30, 2018 at 05:39:46PM +0200, Magnus Hagander wrote: > > On Fri, Mar 30, 2018 at 5:18 PM, Bruce Momjian wrote: > > > > On Fri, Mar 16, 2018 at 01:17:04AM -0300, Euler Taveira wrote: > > > 2018-03-11 1:43 GMT-03:00 PG Doc comments form < > nore...@postgresql.org>: > > > > The documentation for the varbit data type is missing the size > > parameter "[ > > > > (n) ]". > > > > > > > Good catch! It seems to be an oversight in commit > > > 768b647ead78d0d63915c1708cad13c2468f9440. The attached patch adds > it. > > > > Wow, that commit is from 2004. Patch applied and backpatched to v10. > > > > > > If it goes all the way back to 2004, why not backpatch further? > > Uh, I am always debating how important it is to backpatck vs the churn > we require of translations of our docs. In this case, it didn't seem > worthwhile to have all of those translations try to deal with this > change for all those back branches. > > If it's a clean backpatch I'd say it is -- people who are using PostgreSQL 9.6 will be reading the documentation for 9.6 etc, so they will not know about the fix then. If it's not a clean backpatch I can certainly see considering it, but if it's not a lot of effort then I'd say it's definitely worth it. I really don't think considerations for translators of the *docs* are an issue here. If you don't backpatch it, then nobody gets the fix. If you backpatch it, then English readers do get the fix, and translated docs readers *might* get the fix, depending on how they are maintained. It's not like translatable strings where if they change in a backbranch they will revert to English unless the translation is updated -- for the docs, they just don't get the fix. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Documentation for varbit is missing size parameter
On Fri, Mar 30, 2018 at 5:18 PM, Bruce Momjian wrote: > On Fri, Mar 16, 2018 at 01:17:04AM -0300, Euler Taveira wrote: > > 2018-03-11 1:43 GMT-03:00 PG Doc comments form : > > > The documentation for the varbit data type is missing the size > parameter "[ > > > (n) ]". > > > > > Good catch! It seems to be an oversight in commit > > 768b647ead78d0d63915c1708cad13c2468f9440. The attached patch adds it. > > Wow, that commit is from 2004. Patch applied and backpatched to v10. > If it goes all the way back to 2004, why not backpatch further? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Blanks in the first line before the first word in the code boxes
On Thu, Mar 29, 2018 at 4:02 AM, Jonathan S. Katz
wrote:
>
> > On Mar 28, 2018, at 9:47 PM, Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
> >
> > On 3/28/18 21:36, Jonathan S. Katz wrote:
> >>
> >>> On Mar 28, 2018, at 9:32 PM, Peter Eisentraut
> >>> >>> <mailto:peter.eisentr...@2ndquadrant.com>> wrote:
> >>>> Yeah, that looks weird. I'll look into it.
> >>>
> >>> Just looking at a nearby thread ... something is quite whacky with the
> >>> web site stylesheet. It didn't use to look like this. Check this out:
> >>> https://www.postgresql.org/docs/10/static/pgcrypto.html#id-1.11.7.35.5
> >>
> >> Something is adding spaces - it’s within the “” tag, which causes
> >> browsers
> >> to interpret each space literally.
> >>
> >> For the case of the “digest” function, the outputted HTML shows the
> >> first digest
> >> function indented, the second one at the start of the new line.
> >
> > Yeah, the spaces are in the source, so it's not a CSS issue. But it
> > doesn't come out like that if you build the docs locally. So it's
> > something in the web site code.
>
> If I traced the code correctly, the line I suspect is such:
>
> s = tidy.parseString(contents.encode('utf-8'), **tidyopts)
>
> I know that the web infrastructure recently updated to the Django 1.11
> series, I’m not sure if libtidy or the like were also updated with that.
> I’ll
> defer to Magnus on that.
>
This would not change with the change to Django 1.11 -- the actual script
that loads the docs runs outside of Django.
Now, the entire machine was upgraded to a new Debian meaning new python,
new tidy etc some time ago. But this was done the first week of February.
Is it possible that this issue actually showed up around 4-5 February, but
just has gone unnoticed since?
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: libpq options
On Fri, Mar 2, 2018 at 2:50 AM, Michael Paquier wrote: > On Thu, Mar 01, 2018 at 01:35:54AM -0800, Andres Freund wrote: > > On 2017-11-25 19:05:54 +0900, Michael Paquier wrote: > >> A Boolean value of true tells the backend > >> + to go into walsender mode, wherein a small set of replication > commands > >> + can be issued instead of SQL statements. > > > > This actually is wrong now I think. Petr? > > On more or less HEAD: > $ psql -X -d "replication=1 dbname=postgres" > postgres=# create table aa (a int); > ERROR: cannot execute SQL commands in WAL sender for physical replication > $ psql -X -d "replication=database dbname=postgres" > postgres=# create table aa (a int); > CREATE TABLE > > So one needs to use replication=database in order to be able to issue > normal SQL statements, while replication=true enforces physical > replication where this cannot happen (no connection to a specified > database). > To nitpick: + protocol. A Boolean value of true tells the backend We don't really have boolean values here, do we? It's just the string true that's treated as a boolean by the backend. It just sounds really weird to me when written that way. Particularly since the next sentence talks about passing "database" as the same thing. I know that's pretty much nitpicking, but I want to make sure I haven't actually missed/forgotten how some part of that one is handled.. It also talks separately about "going into walsender mode" (=physical replication) and "instructs the walsender to connect to the database". I think that's a bit confusing. I suggest just calling it "physical replication mode" and "logical replication mode", and not bother mentioning walsender since that's quite internal. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Trailing semicolons on partitioning example commands
On Fri, Jan 26, 2018 at 3:27 PM, Daniel Gustafsson wrote: > Is there a reason for not ending all partitioning commands with semicolons > in > the declarative partitioning example? > > https://www.postgresql.org/docs/devel/static/ddl-partitioning.html > > The two last commands with TABLESPACE clauses are ended with semicolons, > the > first three arent. Attached patch adds semicolons such that all are > properly > ended. > I cant see one, since all the other examples do. Thus, pushed. Thanks! -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Is this still accurate?
On Fri, Jan 5, 2018 at 8:09 PM, Jonathan S. Katz wrote: > Hi, > > On Jan 5, 2018, at 1:33 PM, Steve Atkins wrote: > > > On Jan 5, 2018, at 10:00 AM, Stephen Frost wrote: > > Greetings, > > * Moser, Glen G (glen.mo...@charter.com) wrote: > > That's really the gist of the concern from a team member of mine. Not > that the 4TB number is wrong but that it could be misleading to assume that > 4TB is some sort of upper bound. > > That's how this concern was relayed to me and I am just following up. > > > Well, saying 'in excess of' is pretty clear, but I don't think the > sentence is really adding much either, so perhaps we should just remove > it. > > > It's been useful a few times to reassure people that we can handle "large" > databases operationally, rather than just having large theoretical limits. > > Updating it would be great, or wrapping a little more verbiage around the > 4TB number, but a mild -1 on removing it altogether. > > > Here is a proposed patch that updates the wording: > > "There are active PostgreSQL instances in production environments that > manage many terabytes of data, as well as clusters managing petabytes.” > > The idea is that it gives a sense of scope for how big instances/clusters > can run without fixing people on a number. People can draw their own > conclusions from the hard limits further down the page. > > +1. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: J.2. Tool Sets/Appendix J. Documentation missing package
On Fri, Jan 5, 2018 at 7:18 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 1/4/18 09:09, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/0.0/static/docguide-toolsets.html > > Which version of the documentation is this referring to? The 0.0 in the URL means it's the devel version of the docs. Theres a bug that prints it as 0.0 instead of 'devel' it seems. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
