Обсуждение: Problem with pg_upgrade
Hello, I am trying to use pg_upgrade to upgrade data from 9.1.4 to 9.2beta2. Although the upgrade completed successfully, vacuumdb --all --analyze-only gives an error. I tried upgrading two binary backups of the same production database from different days, and both returned the exact same error . The output I got for both trials is as follows: First trial: 1. postgres@sparedb1:/data/pg$ sh analyze_new_cluster.sh 2. This script will generate minimal optimizer statistics rapidly 3. so your system is usable, and then gather statistics twice more 4. with increasing accuracy. When it is done, your system will 5. have the default level of optimizer statistics. 6. 7. If you have used ALTER TABLE to modify the statistics target for 8. any tables, you might want to remove them and restore them after 9. running this script because they will delay fast statistics generation. 10. 11. If you would like default statistics as quickly as possible, cancel 12. this script and run: 13. vacuumdb --all --analyze-only 14. 15. Generating minimal optimizer statistics (1 target) 16. -------------------------------------------------- 17. vacuumdb: vacuuming database "functionx" 18. vacuumdb: vacuuming database "postgres" 19. vacuumdb: vacuuming of database "postgres" failed: ERROR: could not access status of transaction 46675125 20. DETAIL: Could not open file "pg_clog/002C": No such file or directory. 21. 22. The server is now available with minimal optimizer statistics. 23. Query performance will be optimal once this script completes. 24. 25. Generating medium optimizer statistics (10 targets) 26. --------------------------------------------------- 27. vacuumdb: vacuuming database "functionx" 28. vacuumdb: vacuuming database "postgres" 29. vacuumdb: vacuuming of database "postgres" failed: ERROR: could not access status of transaction 46675125 30. DETAIL: Could not open file "pg_clog/002C": No such file or directory. 31. 32. Generating default (full) optimizer statistics (100 targets?) 33. ------------------------------------------------------------- 34. vacuumdb: vacuuming database "functionx" 35. vacuumdb: vacuuming database "postgres" 36. vacuumdb: vacuuming of database "postgres" failed: ERROR: could not access status of transaction 46675125 37. DETAIL: Could not open file "pg_clog/002C": No such file or directory. 38. 39. Done 40. postgres@sparedb1:/data/pg$ Second Trial: 1. postgres@sparedb1:/data/pg$ /opt/pgbrew/9.2beta2}/bin/pg_upgrade -d /data/pg/9.1 -D /data/pg/9.2 -b /opt/pgbrew/9.1.4/bin -B /opt/pgbrew/9 .2beta2}/bin 2. Performing Consistency Checks 3. ----------------------------- 4. Checking current, bin, and data directories ok 5. Checking cluster versions ok 6. Checking database user is a superuser ok 7. Checking for prepared transactions ok 8. Checking for reg* system OID user data types ok 9. Checking for contrib/isn with bigint-passing mismatch ok 10. Creating catalog dump ok 11. Checking for prepared transactions ok 12. Checking for presence of required libraries ok 13. 14. If pg_upgrade fails after this point, you must re-initdb the 15. new cluster before continuing. 16. 17. Performing Upgrade 18. ------------------ 19. Analyzing all rows in the new cluster ok 20. Freezing all rows on the new cluster ok 21. Deleting new commit clogs ok 22. Copying old commit clogs to new server ok 23. Setting next transaction ID for new cluster ok 24. Resetting WAL archives ok 25. Setting frozenxid counters in new cluster ok 26. Creating databases in the new cluster ok 27. Adding support functions to new cluster ok 28. Restoring database schema to new cluster ok 29. Removing support functions from new cluster ok 30. Copying user relation files 31. ok 32. Setting next OID for new cluster ok 33. Creating script to analyze new cluster ok 34. Creating script to delete old cluster ok 35. 36. Upgrade Complete 37. ---------------- 38. Optimizer statistics are not transferred by pg_upgrade so, 39. once you start the new server, consider running: 40. analyze_new_cluster.sh 41. 42. Running this script will delete the old cluster's data files: 43. delete_old_cluster.sh 44. postgres@sparedb1:/data/pg$ echo $PATH 45. /opt/pgbrew/9.2beta2} /bin:/home/postgres/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/opt/dell/srvadmin/bin 46. postgres@sparedb1:/data/pg$ ls 47. 9.1 analyze_new_cluster.sh delete_old_cluster.sh walarchive 48. 9.2 backups loadable_libraries.txt 49. postgres@sparedb1:/data/pg$ /opt/pgbrew/9.2beta2}/bin/pg_ctl status 50. pg_ctl: server is running (PID: 17421) 51. /opt/pgbrew/9.2beta2}/bin/postgres "-D" "/data/pg/9.2" 52. postgres@sparedb1:/data/pg$ vacuumdb --all --analyze-only 53. vacuumdb: vacuuming database "functionx" 54. vacuumdb: vacuuming database "postgres" 55. vacuumdb: vacuuming of database "postgres" failed: ERROR: could not access status of transaction 46675125 56. DETAIL: Could not open file "pg_clog/002C": No such file or directory. 57. postgres@sparedb1:/data/pg$ Regards, Payal Singh
On 07/05/2012 11:20 PM, Payal Singh wrote: > Hello, > > I am trying to use pg_upgrade to upgrade data from 9.1.4 to 9.2beta2. > Although the upgrade completed successfully, vacuumdb --all > --analyze-only gives an error. I tried upgrading two binary backups of > the same production database from different days, and both returned > the exact same error . The output I got for both trials is as follows: Just out of interest, if you try to use pg_ctl to start a 9.1 server from those backups, do they work? Can they be vaccuumed then? If you start 9.1 on a copy of the backup then cleanly stop it again, does pg_upgrade then run? -- Craig Ringer
Thank you. That worked. Regards Payal On Thu, Jul 5, 2012 at 12:15 PM, Craig Ringer <ringerc@ringerc.id.au> wrote: > On 07/05/2012 11:20 PM, Payal Singh wrote: > > Hello, > > I am trying to use pg_upgrade to upgrade data from 9.1.4 to 9.2beta2. > Although the upgrade completed successfully, vacuumdb --all --analyze-only > gives an error. I tried upgrading two binary backups of the same production > database from different days, and both returned the exact same error . The > output I got for both trials is as follows: > > > Just out of interest, if you try to use pg_ctl to start a 9.1 server from > those backups, do they work? Can they be vaccuumed then? > > If you start 9.1 on a copy of the backup then cleanly stop it again, does > pg_upgrade then run? > > -- > Craig Ringer > -- Payal Singh Graduate Student Department of Computer Science and Electrical Engineering University of Maryland, Baltimore County
Payal Singh <payals1@umbc.edu> writes:
> On Thu, Jul 5, 2012 at 12:15 PM, Craig Ringer <ringerc@ringerc.id.au> wrote:
>> If you start 9.1 on a copy of the backup then cleanly stop it again, does
>> pg_upgrade then run?
> Thank you. That worked.
ISTM that pg_upgrade should check that the old cluster was shut down
cleanly, ie pg_control has state = "shut down". AFAICT from some
testing, it currently only checks that there is no postmaster.pid file,
which is easily bypassed by users who might not realize that it's not
safe to run pg_upgrade against a filesystem backup.
BTW, I also noticed while trying to test this that pg_upgrade is
currently completely broken for the case of taking PGDATAOLD or
PGDATANEW from the environment rather than switches. This is because
the existing coding in option.c fails to set up the "pgconfig" fields
in such cases.
regards, tom lane
On Thu, Jul 05, 2012 at 06:28:31PM -0400, Tom Lane wrote: > Payal Singh <payals1@umbc.edu> writes: > > On Thu, Jul 5, 2012 at 12:15 PM, Craig Ringer <ringerc@ringerc.id.au> wrote: > >> If you start 9.1 on a copy of the backup then cleanly stop it again, does > >> pg_upgrade then run? > > > Thank you. That worked. > > ISTM that pg_upgrade should check that the old cluster was shut down > cleanly, ie pg_control has state = "shut down". AFAICT from some > testing, it currently only checks that there is no postmaster.pid file, > which is easily bypassed by users who might not realize that it's not > safe to run pg_upgrade against a filesystem backup. I am confused. pg_upgrade certainly starts/stops the old and new server with pg_ctl before copying any files --- isn't that sufficent? > BTW, I also noticed while trying to test this that pg_upgrade is > currently completely broken for the case of taking PGDATAOLD or > PGDATANEW from the environment rather than switches. This is because > the existing coding in option.c fails to set up the "pgconfig" fields > in such cases. Oh, good catch. Fixed with the attached patch, and backpatched to 9.2. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Вложения
On Fri, Jul 06, 2012 at 01:20:21PM -0400, Payal Singh wrote: > Hi, > > I restored the backup on 9.1, made sure the database reached a consistent state > and checkpointed. Then I performed the upgrade. Upgrade completed successfully > but on running vacuumdb it gave the exact same error. The contents of log file > are: > > > 1. 2012-07-06 12:08:08 EDT [] [21723]: [1-1] user=,db=,e=00000: LOG: database > system was interrupted while in recovery at log time 2012-07-03 03:07:02 > EDT Any idea why you are seeing the above "interrupted while in recovery" message? > 2. 2012-07-06 12:08:08 EDT [] [21723]: [2-1] user=,db=,e=00000: HINT: If this > has occurred more than once some data might be corrupted and you might need > to choose an earlier recovery target. > 3. 2012-07-06 12:08:08 EDT [] [21723]: [3-1] user=,db=,e=00000: LOG: creating > missing WAL directory "pg_xlog/archive_status" > 4. 2012-07-06 12:08:08 EDT [] [21723]: [4-1] user=,db=,e=00000: LOG: database > system was not properly shut down; automatic recovery in progress The above is also confusing. pg_upgrade uses pg_ctl -w stop/start, so I am confused, how it could show as recovering. > > Also, this time I did not run vacuumdb on old server before performing the > upgrade. I think you had better show us exactly what you are doing here --- how you are setting up these clusters, how you are running pg_upgrade, what commands you are typing, etc. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Fri, Jul 06, 2012 at 02:22:28PM -0400, Payal Singh wrote: > The first message in the log is probably because the backup is taken from a > standby. I am using omnipitr-backup-slave to make the backups and then > restoring one of those. OK, this is what I wanted to see. Is the server running while you are taking these backups, because that will not work. > The whole process that I followed is: > > > 1. Restoring backup file: > 2. > 3. payal@sparedb1:/data/pg$ sudo tar -xvzf /mnt/nas/backups/postgres/ > userslave2/backups/data/userslave2.int.functionx.net-xlog-2012-07-03.tar.gz > 489. payal@sparedb1:/data/pg$ sudo tar -xvzf /mnt/nas/backups/postgres/ > userslave2/backups/data/userslave2.int.functionx.net-xlog-2012-07-03.tar.gz > 490. 9.1/pg_xlog/ > 491. 9.1/pg_xlog/000000010000027C00000070 > 492. 9.1/pg_xlog/000000010000027C0000006B.009707C0.backup > 493. 9.1/pg_xlog/000000010000027C0000006D > 494. 9.1/pg_xlog/000000010000027C0000006C > 495. 9.1/pg_xlog/000000010000027C0000006B > 496. 9.1/pg_xlog/000000010000027C0000006E > 497. 9.1/pg_xlog/000000010000027C00000071 > 498. 9.1/pg_xlog/000000010000027C0000006F Why is the xlog backup a separate step? Because it is a separate file system? The system is down, I assume. If you run vacuumedb now, does everything later work fine? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
The omnipitr-backup-slave process takes online backups from the standby, and this is done everyday. This process connects to the master and calls a pg_start_backup and then looks for a restore point on the standby after that WAL address. So i don't think I need to shut down the server. Also, it is the omnipitr-backup-slave process that makes a separate backup for xlog. If you run vacuumedb now, does everything later work fine? I'm not sure about that. Didn't try anything else after that. The 9.2beta2 server starts without errors though. Regards, Payal On Fri, Jul 6, 2012 at 3:30 PM, Bruce Momjian <bruce@momjian.us> wrote: > On Fri, Jul 06, 2012 at 02:22:28PM -0400, Payal Singh wrote: > > The first message in the log is probably because the backup is taken > from a > > standby. I am using omnipitr-backup-slave to make the backups and then > > restoring one of those. > > OK, this is what I wanted to see. Is the server running while you are > taking these backups, because that will not work. > > > The whole process that I followed is: > > > > > > 1. Restoring backup file: > > 2. > > 3. payal@sparedb1:/data/pg$ sudo tar -xvzf /mnt/nas/backups/postgres/ > > > userslave2/backups/data/userslave2.int.functionx.net-xlog-2012-07-03.tar.gz > > > 489. payal@sparedb1:/data/pg$ sudo tar -xvzf /mnt/nas/backups/postgres/ > > > userslave2/backups/data/userslave2.int.functionx.net-xlog-2012-07-03.tar.gz > > 490. 9.1/pg_xlog/ > > 491. 9.1/pg_xlog/000000010000027C00000070 > > 492. 9.1/pg_xlog/000000010000027C0000006B.009707C0.backup > > 493. 9.1/pg_xlog/000000010000027C0000006D > > 494. 9.1/pg_xlog/000000010000027C0000006C > > 495. 9.1/pg_xlog/000000010000027C0000006B > > 496. 9.1/pg_xlog/000000010000027C0000006E > > 497. 9.1/pg_xlog/000000010000027C00000071 > > 498. 9.1/pg_xlog/000000010000027C0000006F > > Why is the xlog backup a separate step? Because it is a separate file > system? The system is down, I assume. > > If you run vacuumedb now, does everything later work fine? > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + > -- Payal Singh Graduate Student Department of Computer Science and Electrical Engineering University of Maryland, Baltimore County
On Fri, Jul 06, 2012 at 04:03:38PM -0400, Payal Singh wrote: > The omnipitr-backup-slave process takes online backups from the standby, and > this is done everyday. This process connects to the master and calls a > pg_start_backup and then looks for a restore point on the standby after that > WAL address. So i don't think I need to shut down the server. My guess is if you try pg_upgrade without omnipitr-backup-slave, and it works, odds are something about your use of omnipitr-backup-slave is wrong. > Also, it is the omnipitr-backup-slave process that makes a separate backup for > xlog. > > > If you run vacuumedb now, does everything later work fine? > > > I'm not sure about that. Didn't try anything else after that. The 9.2beta2 > server starts without errors though. True, but it seems like something it wrong about the cluster, as is shown by vacuumdb. --------------------------------------------------------------------------- > > Regards, > Payal > > On Fri, Jul 6, 2012 at 3:30 PM, Bruce Momjian <bruce@momjian.us> wrote: > > On Fri, Jul 06, 2012 at 02:22:28PM -0400, Payal Singh wrote: > > The first message in the log is probably because the backup is taken from > a > > standby. I am using omnipitr-backup-slave to make the backups and then > > restoring one of those. > > OK, this is what I wanted to see. Is the server running while you are > taking these backups, because that will not work. > > > The whole process that I followed is: > > > > > > 1. Restoring backup file: > > 2. > > 3. payal@sparedb1:/data/pg$ sudo tar -xvzf /mnt/nas/backups/postgres/ > > userslave2/backups/data/ > userslave2.int.functionx.net-xlog-2012-07-03.tar.gz > > > 489. payal@sparedb1:/data/pg$ sudo tar -xvzf /mnt/nas/backups/postgres/ > > userslave2/backups/data/ > userslave2.int.functionx.net-xlog-2012-07-03.tar.gz > > 490. 9.1/pg_xlog/ > > 491. 9.1/pg_xlog/000000010000027C00000070 > > 492. 9.1/pg_xlog/000000010000027C0000006B.009707C0.backup > > 493. 9.1/pg_xlog/000000010000027C0000006D > > 494. 9.1/pg_xlog/000000010000027C0000006C > > 495. 9.1/pg_xlog/000000010000027C0000006B > > 496. 9.1/pg_xlog/000000010000027C0000006E > > 497. 9.1/pg_xlog/000000010000027C00000071 > > 498. 9.1/pg_xlog/000000010000027C0000006F > > Why is the xlog backup a separate step? Because it is a separate file > system? The system is down, I assume. > > If you run vacuumedb now, does everything later work fine? > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + > > > > > -- > Payal Singh > Graduate Student > Department of Computer Science and Electrical Engineering > University of Maryland, Baltimore County -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
If something was wrong with the cluster, why did vacuumdb on new server run successfully when I followed Craig's suggestion of running vacuumdb on old server first, before performing the upgrade, and then ran vacuumdb on new one? On Fri, Jul 6, 2012 at 4:05 PM, Bruce Momjian <bruce@momjian.us> wrote: > On Fri, Jul 06, 2012 at 04:03:38PM -0400, Payal Singh wrote: > > The omnipitr-backup-slave process takes online backups from the standby, > and > > this is done everyday. This process connects to the master and calls a > > pg_start_backup and then looks for a restore point on the standby after > that > > WAL address. So i don't think I need to shut down the server. > > My guess is if you try pg_upgrade without omnipitr-backup-slave, and it > works, odds are something about your use of omnipitr-backup-slave is > wrong. > > > Also, it is the omnipitr-backup-slave process that makes a separate > backup for > > xlog. > > > > > > If you run vacuumedb now, does everything later work fine? > > > > > > I'm not sure about that. Didn't try anything else after that. The > 9.2beta2 > > server starts without errors though. > > True, but it seems like something it wrong about the cluster, as is > shown by vacuumdb. > > --------------------------------------------------------------------------- > > > > > > Regards, > > Payal > > > > On Fri, Jul 6, 2012 at 3:30 PM, Bruce Momjian <bruce@momjian.us> wrote: > > > > On Fri, Jul 06, 2012 at 02:22:28PM -0400, Payal Singh wrote: > > > The first message in the log is probably because the backup is > taken from > > a > > > standby. I am using omnipitr-backup-slave to make the backups and > then > > > restoring one of those. > > > > OK, this is what I wanted to see. Is the server running while you > are > > taking these backups, because that will not work. > > > > > The whole process that I followed is: > > > > > > > > > 1. Restoring backup file: > > > 2. > > > 3. payal@sparedb1:/data/pg$ sudo tar -xvzf > /mnt/nas/backups/postgres/ > > > userslave2/backups/data/ > > userslave2.int.functionx.net-xlog-2012-07-03.tar.gz > > > > > 489. payal@sparedb1:/data/pg$ sudo tar -xvzf > /mnt/nas/backups/postgres/ > > > userslave2/backups/data/ > > userslave2.int.functionx.net-xlog-2012-07-03.tar.gz > > > 490. 9.1/pg_xlog/ > > > 491. 9.1/pg_xlog/000000010000027C00000070 > > > 492. 9.1/pg_xlog/000000010000027C0000006B.009707C0.backup > > > 493. 9.1/pg_xlog/000000010000027C0000006D > > > 494. 9.1/pg_xlog/000000010000027C0000006C > > > 495. 9.1/pg_xlog/000000010000027C0000006B > > > 496. 9.1/pg_xlog/000000010000027C0000006E > > > 497. 9.1/pg_xlog/000000010000027C00000071 > > > 498. 9.1/pg_xlog/000000010000027C0000006F > > > > Why is the xlog backup a separate step? Because it is a separate > file > > system? The system is down, I assume. > > > > If you run vacuumedb now, does everything later work fine? > > > > -- > > Bruce Momjian <bruce@momjian.us> http://momjian.us > > EnterpriseDB http://enterprisedb.com > > > > + It's impossible for everything to be true. + > > > > > > > > > > -- > > Payal Singh > > Graduate Student > > Department of Computer Science and Electrical Engineering > > University of Maryland, Baltimore County > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + > -- Payal Singh Graduate Student Department of Computer Science and Electrical Engineering University of Maryland, Baltimore County
On Fri, Jul 06, 2012 at 04:21:06PM -0400, Payal Singh wrote: > If something was wrong with the cluster, why did vacuumdb on new server run > successfully when I followed Craig's suggestion of running vacuumdb on old > server first, before performing the upgrade, and then ran vacuumdb on new one? My guess is there is something odd about the old cluster that was somehow fixed by the vacuumedb on the old clsuter that can't be fixed by vacuumdb on the new cluster. --------------------------------------------------------------------------- > > On Fri, Jul 6, 2012 at 4:05 PM, Bruce Momjian <bruce@momjian.us> wrote: > > On Fri, Jul 06, 2012 at 04:03:38PM -0400, Payal Singh wrote: > > The omnipitr-backup-slave process takes online backups from the standby, > and > > this is done everyday. This process connects to the master and calls a > > pg_start_backup and then looks for a restore point on the standby after > that > > WAL address. So i don't think I need to shut down the server. > > My guess is if you try pg_upgrade without omnipitr-backup-slave, and it > works, odds are something about your use of omnipitr-backup-slave is > wrong. > > > Also, it is the omnipitr-backup-slave process that makes a separate > backup for > > xlog. > > > > > > If you run vacuumedb now, does everything later work fine? > > > > > > I'm not sure about that. Didn't try anything else after that. The > 9.2beta2 > > server starts without errors though. > > True, but it seems like something it wrong about the cluster, as is > shown by vacuumdb. > > --------------------------------------------------------------------------- > > > > > > Regards, > > Payal > > > > On Fri, Jul 6, 2012 at 3:30 PM, Bruce Momjian <bruce@momjian.us> wrote: > > > > On Fri, Jul 06, 2012 at 02:22:28PM -0400, Payal Singh wrote: > > > The first message in the log is probably because the backup is > taken from > > a > > > standby. I am using omnipitr-backup-slave to make the backups and > then > > > restoring one of those. > > > > OK, this is what I wanted to see. Is the server running while you > are > > taking these backups, because that will not work. > > > > > The whole process that I followed is: > > > > > > > > > 1. Restoring backup file: > > > 2. > > > 3. payal@sparedb1:/data/pg$ sudo tar -xvzf /mnt/nas/backups/ > postgres/ > > > userslave2/backups/data/ > > userslave2.int.functionx.net-xlog-2012-07-03.tar.gz > > > > > 489. payal@sparedb1:/data/pg$ sudo tar -xvzf /mnt/nas/backups/ > postgres/ > > > userslave2/backups/data/ > > userslave2.int.functionx.net-xlog-2012-07-03.tar.gz > > > 490. 9.1/pg_xlog/ > > > 491. 9.1/pg_xlog/000000010000027C00000070 > > > 492. 9.1/pg_xlog/000000010000027C0000006B.009707C0.backup > > > 493. 9.1/pg_xlog/000000010000027C0000006D > > > 494. 9.1/pg_xlog/000000010000027C0000006C > > > 495. 9.1/pg_xlog/000000010000027C0000006B > > > 496. 9.1/pg_xlog/000000010000027C0000006E > > > 497. 9.1/pg_xlog/000000010000027C00000071 > > > 498. 9.1/pg_xlog/000000010000027C0000006F > > > > Why is the xlog backup a separate step? Because it is a separate > file > > system? The system is down, I assume. > > > > If you run vacuumedb now, does everything later work fine? > > > > -- > > Bruce Momjian <bruce@momjian.us> http://momjian.us > > EnterpriseDB http://enterprisedb.com > > > > + It's impossible for everything to be true. + > > > > > > > > > > -- > > Payal Singh > > Graduate Student > > Department of Computer Science and Electrical Engineering > > University of Maryland, Baltimore County > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + > > > > > -- > Payal Singh > Graduate Student > Department of Computer Science and Electrical Engineering > University of Maryland, Baltimore County -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Okay. I guess so. Thanks for your help. Regards, Payal On Fri, Jul 6, 2012 at 4:24 PM, Bruce Momjian <bruce@momjian.us> wrote: > On Fri, Jul 06, 2012 at 04:21:06PM -0400, Payal Singh wrote: > > If something was wrong with the cluster, why did vacuumdb on new server > run > > successfully when I followed Craig's suggestion of running vacuumdb on > old > > server first, before performing the upgrade, and then ran vacuumdb on > new one? > > My guess is there is something odd about the old cluster that was > somehow fixed by the vacuumedb on the old clsuter that can't be fixed by > vacuumdb on the new cluster. > > --------------------------------------------------------------------------- > > > > > > On Fri, Jul 6, 2012 at 4:05 PM, Bruce Momjian <bruce@momjian.us> wrote: > > > > On Fri, Jul 06, 2012 at 04:03:38PM -0400, Payal Singh wrote: > > > The omnipitr-backup-slave process takes online backups from the > standby, > > and > > > this is done everyday. This process connects to the master and > calls a > > > pg_start_backup and then looks for a restore point on the standby > after > > that > > > WAL address. So i don't think I need to shut down the server. > > > > My guess is if you try pg_upgrade without omnipitr-backup-slave, and > it > > works, odds are something about your use of omnipitr-backup-slave is > > wrong. > > > > > Also, it is the omnipitr-backup-slave process that makes a separate > > backup for > > > xlog. > > > > > > > > > If you run vacuumedb now, does everything later work fine? > > > > > > > > > I'm not sure about that. Didn't try anything else after that. The > > 9.2beta2 > > > server starts without errors though. > > > > True, but it seems like something it wrong about the cluster, as is > > shown by vacuumdb. > > > > > --------------------------------------------------------------------------- > > > > > > > > > > Regards, > > > Payal > > > > > > On Fri, Jul 6, 2012 at 3:30 PM, Bruce Momjian <bruce@momjian.us> > wrote: > > > > > > On Fri, Jul 06, 2012 at 02:22:28PM -0400, Payal Singh wrote: > > > > The first message in the log is probably because the backup > is > > taken from > > > a > > > > standby. I am using omnipitr-backup-slave to make the > backups and > > then > > > > restoring one of those. > > > > > > OK, this is what I wanted to see. Is the server running while > you > > are > > > taking these backups, because that will not work. > > > > > > > The whole process that I followed is: > > > > > > > > > > > > 1. Restoring backup file: > > > > 2. > > > > 3. payal@sparedb1:/data/pg$ sudo tar -xvzf > /mnt/nas/backups/ > > postgres/ > > > > userslave2/backups/data/ > > > userslave2.int.functionx.net-xlog-2012-07-03.tar.gz > > > > > > > 489. payal@sparedb1:/data/pg$ sudo tar -xvzf > /mnt/nas/backups/ > > postgres/ > > > > userslave2/backups/data/ > > > userslave2.int.functionx.net-xlog-2012-07-03.tar.gz > > > > 490. 9.1/pg_xlog/ > > > > 491. 9.1/pg_xlog/000000010000027C00000070 > > > > 492. 9.1/pg_xlog/000000010000027C0000006B.009707C0.backup > > > > 493. 9.1/pg_xlog/000000010000027C0000006D > > > > 494. 9.1/pg_xlog/000000010000027C0000006C > > > > 495. 9.1/pg_xlog/000000010000027C0000006B > > > > 496. 9.1/pg_xlog/000000010000027C0000006E > > > > 497. 9.1/pg_xlog/000000010000027C00000071 > > > > 498. 9.1/pg_xlog/000000010000027C0000006F > > > > > > Why is the xlog backup a separate step? Because it is a > separate > > file > > > system? The system is down, I assume. > > > > > > If you run vacuumedb now, does everything later work fine? > > > > > > -- > > > Bruce Momjian <bruce@momjian.us> http://momjian.us > > > EnterpriseDB > http://enterprisedb.com > > > > > > + It's impossible for everything to be true. + > > > > > > > > > > > > > > > -- > > > Payal Singh > > > Graduate Student > > > Department of Computer Science and Electrical Engineering > > > University of Maryland, Baltimore County > > > > -- > > Bruce Momjian <bruce@momjian.us> http://momjian.us > > EnterpriseDB http://enterprisedb.com > > > > + It's impossible for everything to be true. + > > > > > > > > > > -- > > Payal Singh > > Graduate Student > > Department of Computer Science and Electrical Engineering > > University of Maryland, Baltimore County > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + > -- Payal Singh Graduate Student Department of Computer Science and Electrical Engineering University of Maryland, Baltimore County