Re: Upgrading to v12

On 11/28/22 17:02, Tom Lane wrote: Brad White writes: I tried to run initdb after re-installing pg 12 using postgresql-12.10-2-windows-x64.exe. But the runas I'm using to execute it as pguser seems to be swallowing all the output, so I can't see any errors. I was able to run pg_checksums and ge

Re: Upgrading to v12

Brad White writes: > I tried to run initdb after re-installing pg 12 > using postgresql-12.10-2-windows-x64.exe. > But the runas I'm using to execute it as pguser seems to be swallowing all > the output, so I can't see any errors. > I was able to run pg_checksums and get those enabled. > Is there

Re: Upgrading to v12

Tom, I tried to run initdb after re-installing pg 12 using postgresql-12.10-2-windows-x64.exe. But the runas I'm using to execute it as pguser seems to be swallowing all the output, so I can't see any errors. I was able to run pg_checksums and get those enabled. Is there anything else I want from i

Re: Upgrading to v12

On 11/22/22 12:53, Brad White wrote: On 11/18/2022 6:34 PM, Adrian Klaver wrote: On 11/18/22 16:05, Brad White wrote: --> The Microsoft Access database engine stopped the process because you and another user are attempting to change the same data at the same time. Code in question:       

Re: Upgrading to v12

On 11/18/2022 6:34 PM, Adrian Klaver wrote: On 11/18/22 16:05, Brad White wrote: --> The Microsoft Access database engine stopped the process because you and another user are attempting to change the same data at the same time. Code in question:       rst!Update  <-- success       rst!Qty

Re: Upgrading to v12

On 11/18/22 16:05, Brad White wrote: tl;dr  How do I turn up the logging so I can see what is failing? In our quest to get replication working, we are upgrading from v9.4 to v12.10. Access365 via ODBC Driver = "PostgreSQL Unicode" v13.02, Date 9/22/2021 In testing the app against v12, I find

Re: Upgrading to v12

tl;dr How do I turn up the logging so I can see what is failing? In our quest to get replication working, we are upgrading from v9.4 to v12.10. Access365 via ODBC Driver = "PostgreSQL Unicode" v13.02, Date 9/22/2021 In testing the app against v12, I find this issue: On updating a record, I set

Re: Upgrading to v12

On 11/12/22 22:07, Tom Lane wrote: Ron writes: On 11/11/22 23:09, Adrian Klaver wrote: 2) For your explanation above, pg_dump from 9.4(5432) to pg_restore 12(5433) the issue would be ...\9.4\bin\pg_dump.exe of 9.4 and pg_restore of said dump file to version 12. When moving up in version you ne

Re: Upgrading to v12

On 11/12/22 18:18, Brad White wrote: >  How where the restored copies made on the original cluster? I guess I'm not understanding the confusion here. They were restored with the same script but to a different DB name and with the 9.4 executables. In fact, that was why the scr

Re: Upgrading to v12

Ron writes: > On 11/11/22 23:09, Adrian Klaver wrote: >> 2) For your explanation above, pg_dump from 9.4(5432) to pg_restore >> 12(5433) the issue would be ...\9.4\bin\pg_dump.exe of 9.4 and pg_restore >> of said dump file to version 12. When moving up in version you need to use >> the newer ve

Re: Upgrading to v12

On 11/11/22 23:09, Adrian Klaver wrote: On 11/11/22 20:59, Brad White wrote: On Fri, Nov 11, 2022, 9:57 PM Adrian Klaver > wrote: Yes. The backup is from production. V9.4 is running on 5432 on all servers. That particular restore happens to be on the dev serve

Re: Upgrading to v12

> > > > How where the restored copies made on the original cluster? > I guess I'm not understanding the confusion here. They were restored with > the same script but to a different DB name and with the 9.4 executables. > In fact, that was why the script was originally written, so we could > restor

Re: Upgrading to v12

> If the client lets you, of course. Right? 8: -) That's not a concern here. A) They trust me, and B) They only see the front end. They don't really care what happens with the back end. so long as A) It doesn't break, and B) We get replication working. >

Re: Upgrading to v12

> Step #1: upgrade to 9.4.26. You'll get *five years* of bug fixes. Good idea. I'll try 12 first, and if that doesn't work we'll go with this. >

Re: Upgrading to v12

> When moving up in version you need to use the newer version of pg_dump(...\12\bin\pg_dump.exe) to dump the 9.4 instance and then the version 12 pg_restore to the 12 instance. Oh my. That's a substantial change that could make a difference. Thanks for catching that. > >

Re: Upgrading to v12

Step #1: upgrade to 9.4.26.  You'll get *five years* of bug fixes. (If the client lets you, of course.  I had servers stuck on 8.4.17 and 9.2.7 that were only upgraded because PCI auditors were going to tell my client's client, and that scared /my/ client.  Now they're on 9.6.24...) On 11/11/

Re: Upgrading to v12

On 11/11/22 20:59, Brad White wrote: On Fri, Nov 11, 2022, 9:57 PM Adrian Klaver > wrote: Yes. The backup is from production. V9.4 is running on 5432 on all servers. That particular restore happens to be on the dev server. 5433 is v12. 1) This does not addre

Re: Upgrading to v12

On Fri, Nov 11, 2022, 9:57 PM Adrian Klaver wrote: > On 11/11/22 18:41, Brad White wrote: > > > From your original post, what did "Not the half dozen restored copies" > > mean? > > Over time, we've restored multiple copies for testing and reproducing > > various issues. > > > > I'm only trying t

Re: Upgrading to v12

On 11/11/22 18:41, Brad White wrote: > From your original post, what did "Not the half dozen restored copies" mean? Over time, we've restored multiple copies for testing and reproducing various issues. I'm only trying to set up replication one one of those copies. > In other words define th

Re: Upgrading to v12

Sorry. Ignore the errors. That was mistakenly copied in from elsewhere.

Re: Upgrading to v12

> From your original post, what did "Not the half dozen restored copies" mean? Over time, we've restored multiple copies for testing and reproducing various issues. I'm only trying to set up replication one one of those copies. > In other words define the restore process. Command to back up the

Re: Upgrading to v12

On 11/11/22 14:06, Brad White wrote: > Can you do a pg_dump of that database? Yes. No visible problems. No errors reported. From your original post, what did "Not the half dozen restored copies" mean? In other words define the restore process. -- Adrian Klaver adrian.kla...@aklaver.com

Re: Upgrading to v12

Brad White writes: >> Can you do a pg_dump of that database? > Yes. No visible problems. No errors reported. Well, that's quite interesting, because pg_dump ought to read all the same catalogs that pg_upgrade is failing to read. So I'm not quite sure what's going on there. Nonetheless, your pat

Re: Upgrading to v12

> Can you do a pg_dump of that database? Yes. No visible problems. No errors reported. On Fri, Nov 11, 2022 at 3:17 PM Adrian Klaver wrote: > On 11/11/22 13:11, Brad White wrote: > > I deleted all the other DBs and left only the primary. > > Still getting the same error message, ending with > >

Re: Upgrading to v12

I'm practicing on our Dev server, so I can blow this away and reload at any time. Are there any utilities to check for corruption on my Prod server in v9.4.1? All my backups are done with pg_dump.exe, so that's where this database came from in the first place. So we know that pg_dump.exe works on

Re: Upgrading to v12

On 11/11/22 13:11, Brad White wrote: I deleted all the other DBs and left only the primary. Still getting the same error message, ending with ERROR:  could not access status of transaction 22316920 DETAIL:  Could not read from file "pg_clog/0015" at offset 73728: No error. Can you do a pg_dump

Re: Upgrading to v12

Brad White writes: > I deleted all the other DBs and left only the primary. > Still getting the same error message, ending with > ERROR: could not access status of transaction 22316920 > DETAIL: Could not read from file "pg_clog/0015" at offset 73728: No error. That's a pretty clear indication

Re: Upgrading to v12

I deleted all the other DBs and left only the primary. Still getting the same error message, ending with ERROR: could not access status of transaction 22316920 DETAIL: Could not read from file "pg_clog/0015" at offset 73728: No error.

Re: Upgrading to v12

> What was the complete pg_upgrade command you used? "C:\Program Files\PostgreSQL\12\bin\pg_upgrade" -d "C:\Program Files\PostgreSQL\9.4\data" -D "C:\Program Files\PostgreSQL\12\data" -b "C:\Program Files\PostgreSQL\9.4\bin" -B "C:\Program Files\PostgreSQL\12\bin" -U postgres -p 5432 -P 5435 > >

Re: Upgrading to v12

On 11/11/22 12:43, Brad White wrote: I'm upgrading from v9.4 to v12.10 as a half step to 15. Q1: How do I tell it which database to upgrade? I only need the primary. Not the half dozen restored copies. Or do I need to detach everything I don't want copied? 1) If you are using pg_upgrade then i

Upgrading to v12

I'm upgrading from v9.4 to v12.10 as a half step to 15. Q1: How do I tell it which database to upgrade? I only need the primary. Not the half dozen restored copies. Or do I need to detach everything I don't want copied? Q2: I get this error, and then at the end, it says "No error." Performing Co