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. +
Attachments:
pg_upgrade.difftext/x-diff; charset=us-asciiDownload+23-19
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. +
Import Notes
Reply to msg id not found: CAK4ounxaUVnPADZf5f5bABZRZfa99BnayH4n8Ywd-PkY3C3NpQ@mail.gmail.com
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. +
Import Notes
Reply to msg id not found: CAK4ounxb-1wJw9SQth_LmXeOE4+=nK7w5GxSOPf8pnR88BZpJQ@mail.gmail.com
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/000000010000027C0000006FWhy 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,
PayalOn 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/000000010000027C0000006FWhy 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 afterthat
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,
PayalOn 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/000000010000027C0000006FWhy 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 afterthat
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,
PayalOn 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/000000010000027C0000006FWhy 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,
PayalOn 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/000000010000027C0000006FWhy 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+ 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