Re: Postgres upgrade trouble
On Mon, May 28, 2018 at 01:48:58PM -0400, Bruce Momjian wrote: > On Fri, May 11, 2018 at 07:15:41AM +, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/10/static/pgupgrade.html > > Description: > > > > This is a non IT specialist question / comments. I like postgres, except the > > current automatic upgrade mechanism working on my server... > > On my Ubuntu 16.04 machine, when a postgres upgrade comes and installs > > automatically, this creates a real nightmare: neither pgAdminIII not my > > application can access the DB. (connection refused. Is the server running... > > ...on port 5432?) > > Trying to understand in the documentation what to do is very difficult > > because there is no clear example on how to retreive the 'old' or 'new' > > parameters. So, I wonder why there is no automatic mechanism coming with the > > upgrade to change the settings automatically, or alternatively to keep the > > 'old' version up and running correctly (and in this case the end user should > > have an easy way to know that he has to launch an upgrade when he wants to, > > and an utility -for instance in pgAdmin- should guide him along this upgrade > > mechanism, ensuring I do not loose time nor any data). > > Thanks for your efforts to offer Postgres to the IT community! > > This is really something for you to address with Ubuntu. The Postgres > community provides the tools, but the user interface is often up to the > packagers. I agree the interface is complex. > I agree this is really a distro and user problem. Most upgrades are "fire and forget" process, but databases and some other applications really need user input for successful completion. Unfortunately, this requires the user to have the necessary level of expertise, preferably before the update takes place. I'm guessing that Ubuntu, or other distro has decided to be prudent in their process and settings. Their choice may be to make things easy and place the user's data at risk, or to provide via an abundance of caution, a more difficult experience for the user. For example, I have altered the postgres files that control configuration and access. It is clearly my responsibility to record and maintain those files. Similarly, while the distro may provide a "Are you Sure" type query during the database upgrade process, the settings for the dist-upgrade in apt-get or dselect are under my control, and I can defer the upgrade to a time of my choosing, usually as part of a more major upgrade. That said, I've been through the process the OP describes. HTH Richard A Lough
how to modify the navfooter
Where is the content of the navfooter established? I would like to make some modifications to this footer, but I am unable to figure out where the source that generates it. I am building the documentation following the instructions from "Building The Documentation" in Appendix J, currently on 9.6. I am using the command: make STYLE=website html I can see the generated navfooter div section in the output html. I must be missing something, because I cannot find a file in the git branch that includes the class named "navfooter" or or any other words like "Navigation footer", "Next", or "Prev". I have limited understanding of stylesheets (whether dsl or xsl), but I am hoping that I can make the small modifications needed for our use. I am also curious about the docFooter div section that appears in the publicly published PostgreSQL documentation pages. It does not appear when I build the docs. Is there a reason that the copyright does not appear on each page when I do the doc build? Is there some way to get it included when I do the doc build? What file is used that contains the format (style?) info for that generated html div section? I would appreciate any assistance from those in the community that understand something about these footers. ...Rick Swagerman
Re: how to modify the navfooter
Thank you Tom and Jonathan for your responses. I am now looking at the stylesheet.xsl from after 9.6, and I do see these lines in the file: The generated html files clearly have a div tag and a table tag that match this. So I can understand what generates the header. What baffles me is that the generated html files also include these tags at the bottom of each file: I do not see anything in stylesheet.xsl that looks anything like this. Does anyone know where the "magic incantations" are that generate this navfooter? ...Rick Swagerman On Tue, Aug 7, 2018 at 6:45 PM, Jonathan S. Katz wrote: > > On Aug 7, 2018, at 6:21 PM, Richard Swagerman > wrote: > > Where is the content of the navfooter established? > I would like to make some modifications to this footer, but I am unable to > figure out where the source that generates it. > > I am building the documentation following the instructions from "Building > The Documentation" in Appendix J, currently on 9.6. > > I am using the command: > make STYLE=website html > > I can see the generated navfooter div section in the output html. I must > be missing something, because I cannot find a file in the git branch that > includes the class named "navfooter" or or any other words like "Navigation > footer", "Next", or "Prev". > > I have limited understanding of stylesheets (whether dsl or xsl), but I am > hoping that I can make the small modifications needed for our use. > > > I’m not as familiar with the doc builds but it looks like this is > available > in the “stylesheet.xsl” file. > > I am also curious about the docFooter div section that appears in the > publicly published PostgreSQL documentation pages. It does not appear when > I build the docs. > Is there a reason that the copyright does not appear on each page when I > do the doc build? > Is there some way to get it included when I do the doc build? > What file is used that contains the format (style?) info for that > generated html div section? > > > That is in the pgweb[1] project, i.e. this file[2]. My understanding > is that probably will not be included in the doc build, as there is > content in it that is specific to the website :-) > > [1] https://git.postgresql.org/gitweb/?p=pgweb.git;a=summary > [2] https://git.postgresql.org/gitweb/?p=pgweb.git;a= > blob;f=templates/docs/docspage.html; > <https://git.postgresql.org/gitweb/?p=pgweb.git;a=blob;f=templates/docs/docspage.html;h=3c5535b43a6f60328bde1bf28903db5bcf81277a;hb=HEAD> >
password storage docs
Hi, Sending this as requested by xocolatl on #postgresql (irc). On discovering that (md5) password hashes are stored in postgres in a manner similar to this: 'md5' || md5('the most secret password' || 'username') i.e. without the use of a random salt, it was suggested I should look into the scram alternative. I can't find information about the storage format for that at all - other than "... and supports storing passwords on the server in a cryptographically hashed form that is thought to be secure." It would be nice to see more information on this. Thanks, Richard
Re: CLUSTER command
That makes perfect sense, now that you have explained it. I just didn't pick up on that from the text as written. -- D. Richard Hipp d...@sqlite.org On Wednesday, October 16th, 2024 at 9:22 AM, Alvaro Herrera wrote: > Hello, > > On 2024-Oct-15, PG Doc comments form wrote: > > > The documentation does not say what happens if you do "CLUSTER tablename" > > and omit the USING clause, which is shown as optional in the BNF, if I'm > > reading it right. Does CLUSTER use the PRIMARY KEY in that case? What if > > no PRIMARY KEY is specified? > > > The table is clustered on the index that was previously selected as the > cluster index (either by running "CLUSTER table ON idx" or by doing > ALTER TABLE tab CLUSTER ON idx"). If no index is selected, an error is > thrown. > > The docs explain it this way: > > When a table is clustered, PostgreSQL remembers which index it was clustered > by. The form CLUSTER table_name reclusters the table using the same index as > before. You can also use the CLUSTER or SET WITHOUT CLUSTER forms of ALTER > TABLE to set the index to be used for future cluster operations, or to clear > any previous setting. > > I'm not sure if we need to make this clearer. It's perfectly clear to > me, but then I already knew what I wanted to read ... > > -- > Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ > "After a quick R of TFM, all I can say is HOLY CR** THAT IS COOL! PostgreSQL > was > amazing when I first started using it at 7.2, and I'm continually astounded by > learning new features and techniques made available by the continuing work of > the development team." > Berend Tober, > http://archives.postgresql.org/pgsql-hackers/2007-08/msg01009.php