Even more OT: Ditto machines [was: bottom / top posting]
On 2021-06-10 13:21, Peter J. Holzer wrote: On 2021-06-09 14:41:47 -0700, Dean Gibson (DB Administrator) wrote: ... when paper memos were the norm ... ... before photocopiers were invented... Tom mentioned "old-timers." Remember "Ditto" machines? Remember the odor? They were in common use when I was in high school (1960). https://en.wikipedia.org/wiki/Mimeograph
Re: bottom / top posting
On Mon, Jun 7, 2021 at 07:53:30PM +0200, Francisco Olarte wrote: ... properly scanning a top posted one takes much longer. Not here. I find top-posting moderately offensive, like saying "I am not going to waste time to make your reading experience better". Not here either. Top-posting has been the predominantly common practice in the business & government world for decades, & it is easy to adapt to. Just like HTML eMail (within reason) & more than 80 columns on a line. Somehow, millions of ordinary people are able to adapt to this, on very popular network eMail providers, like Google groups & groups.io, as well as their work environment. I suppose it comes from the practice in those environs when paper memos were the norm, & if you needed to attach the contents of other paper memos to your own for context, you stapled them to the BACK of your own. Of course, wherever (top/bottom) one posts, trimming is important, but it's far less important with top-posting. You usually don't have to scroll down to get the immediate context, & if you do, you have less far to scroll. I wonder about the tolerance of the world we live in. Somehow, I can deal with top-posting, bottom-posting, middle-posting, HTML eMail, straight-text eMails, 80-column eMails, variable-width eMails, occasional ALL CAPS eMails, & stupid multi-line signatures, all without getting my tail in a knot over it. But then, I was VERY successful in my software development career, consulting at about 30 companies (now retired). Maybe working with others without conflict on silly issues, had something to do with it. This message would normally have been top-posted, but was bottom-posted to avoid offending or irritating people here. Seriously. ps: The people on this list have been very helpful, despite the above.
Re: bottom / top posting
And do not get me started on the "sent from my iPhone / yahoo mail for Android / ...", above/below the megaquote in mailing lists like this. And then there's the wonderful signatures stating that there were no viruses in the outgoing message ...
Re: AWS forcing PG upgrade from v9.6 a disaster
On 2021-05-28 16:51, Ron wrote: On 5/28/21 5:06 PM, Dean Gibson (DB Administrator) wrote: On 2021-05-28 12:38, Ron wrote: On 5/28/21 1:40 PM, Dean Gibson (DB Administrator) wrote: On 2021-05-28 08:12, Adrian Klaver wrote: On 5/27/21 8:41 PM, Dean Gibson (DB Administrator) wrote: I started to use PostgreSQL v7.3 in 2003 on my home Linux systems (4 at one point), gradually moving to v9.0 w/ replication in 2010. In 2017 I moved my 20GB database to AWS/RDS, gradually upgrading to v9.6, & was entirely satisfied with the result. In March of this year, AWS announced that v9.6 was nearing end of support, & AWS would forcibly upgrade everyone to v12 on January 22, 2022, if users did not perform the upgrade earlier. My first attempt was successful as far as the upgrade itself, but complex queries that normally ran in a couple of seconds on v9.x, were taking minutes in v12. Did you run a plain ANALYZE(https://www.postgresql.org/docs/12/sql-analyze.html) on the tables in the new install? After each upgrade (to 10, 11, 12, & 13), I did a "VACUUM FULL ANALYZE". On 10 through 12, it took about 45 minutes & significant CPU activity, & temporarily doubled the size of the disk space required. As you know, that disk space is not shrinkable under AWS's RDS. On v13, it took 10 hours with limited CPU activity, & actually slightly less disk space required. Under normal conditions, VACUUM FULL is pointless on a freshly-loaded database; in RDS, it's *anti-useful*. That's why Adrian asked if you did a plain ANALYZE. Just now did. No change in EXPLAIN ANALYZE output. Did it run in less than 10 hours? The original VACUUM FULL ANALYZE ran in 10 hours. The plain ANALYZE ran in 88 seconds.
Re: AWS forcing PG upgrade from v9.6 a disaster
On 2021-05-28 12:38, Ron wrote: On 5/28/21 1:40 PM, Dean Gibson (DB Administrator) wrote: On 2021-05-28 08:12, Adrian Klaver wrote: On 5/27/21 8:41 PM, Dean Gibson (DB Administrator) wrote: I started to use PostgreSQL v7.3 in 2003 on my home Linux systems (4 at one point), gradually moving to v9.0 w/ replication in 2010. In 2017 I moved my 20GB database to AWS/RDS, gradually upgrading to v9.6, & was entirely satisfied with the result. In March of this year, AWS announced that v9.6 was nearing end of support, & AWS would forcibly upgrade everyone to v12 on January 22, 2022, if users did not perform the upgrade earlier. My first attempt was successful as far as the upgrade itself, but complex queries that normally ran in a couple of seconds on v9.x, were taking minutes in v12. Did you run a plain ANALYZE(https://www.postgresql.org/docs/12/sql-analyze.html) on the tables in the new install? After each upgrade (to 10, 11, 12, & 13), I did a "VACUUM FULL ANALYZE". On 10 through 12, it took about 45 minutes & significant CPU activity, & temporarily doubled the size of the disk space required. As you know, that disk space is not shrinkable under AWS's RDS. On v13, it took 10 hours with limited CPU activity, & actually slightly less disk space required. Under normal conditions, VACUUM FULL is pointless on a freshly-loaded database; in RDS, it's *anti-useful*. That's why Adrian asked if you did a plain ANALYZE. Just now did. No change in EXPLAIN ANALYZE output.
Re: AWS forcing PG upgrade from v9.6 a disaster
On 2021-05-28 08:12, Adrian Klaver wrote: On 5/27/21 8:41 PM, Dean Gibson (DB Administrator) wrote: I started to use PostgreSQL v7.3 in 2003 on my home Linux systems (4 at one point), gradually moving to v9.0 w/ replication in 2010. In 2017 I moved my 20GB database to AWS/RDS, gradually upgrading to v9.6, & was entirely satisfied with the result. In March of this year, AWS announced that v9.6 was nearing end of support, & AWS would forcibly upgrade everyone to v12 on January 22, 2022, if users did not perform the upgrade earlier. My first attempt was successful as far as the upgrade itself, but complex queries that normally ran in a couple of seconds on v9.x, were taking minutes in v12. Did you run a plain ANALYZE(https://www.postgresql.org/docs/12/sql-analyze.html) on the tables in the new install? After each upgrade (to 10, 11, 12, & 13), I did a "VACUUM FULL ANALYZE". On 10 through 12, it took about 45 minutes & significant CPU activity, & temporarily doubled the size of the disk space required. As you know, that disk space is not shrinkable under AWS's RDS. On v13, it took 10 hours with limited CPU activity, & actually slightly less disk space required.
Re: How long to get a password reset ???
It's pretty simple: 1. Not having used this mailing list for a while, I went to https://lists.postgresql.org/ to make sure my settings were as I wanted them. 2. I attempted to log in with the above eMail address, which is obviously part of this list, since I receive messages to that address from this list. 3. All known passwords failed. 4. I clicked on the link to the "password reset" form, entered my above eMail address, & pressed "Reset Password." The response was a web page that said I'd soon get an eMail for resetting my password. 5. The rest is history. Meaning zero history (response). And yes, I did it twice to make sure I didn't type the eMail address incorrectly (I cut & pasted the 2nd time). I can try again if it will help (barring the usual definition of insanity). That was six hours ago. Since it looks like I (now) have satisfactory access to the list (I was moderated for a few hours), I will post (in a separate thread) my PostgreSQL issue, & wait for the next full moon (26 days) for my password reset. On 2021-05-27 16:09, Adrian Klaver wrote: On 5/27/21 4:06 PM, Adrian Klaver wrote: On 5/27/21 11:51 AM, Dean Gibson (DB Administrator) wrote: I have a continuous log feed from my mail server, showing that I've received list eMail to the above eMail address, as recently as this morning. Obviously, eMail is not being blocked at this end. But no responses to a password reset for the above eMail address. Password reset from where? I should have added, for your community account or for something else? Sincerely, Dean
How long to get a password reset ???
I have a continuous log feed from my mail server, showing that I've received list eMail to the above eMail address, as recently as this morning. Obviously, eMail is not being blocked at this end. But no responses to a password reset for the above eMail address. Sincerely, Dean
Re: Migration to PGLister - After
My procmail filter is now: * H ?? ^TO_pgsql-.*@(lists.)?postgresql.org On 2017-11-20 09:49, Rich Shepard wrote: On Mon, 20 Nov 2017, Joshua D. Drake wrote: Yep, but that is why the list-id filter is bad advice (at least for me). I filter on the list email address and it works flawlessly. Joshua, This does not work if the procmail recipe is for pgsql-gene...@postgresql.org and the source includes the server; e.g, pgsql-general@lists.postgresql.org. Perhaps adding '.*' in front of postgresql.org will fix this. Rich
