Re: [GENERAL] Urgent Help Required
On 10/08/2013 03:55 AM, shailesh singh wrote: I had got this message while running vacuum full from backend . Now My database is not starting , Help pls. backend vacuum full debug; WARNING: database debug must be vacuumed within 99 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in debug. ERROR: relation debug does not exist Now what? First some information. 1) What version of Postgres are you using? 2) Does database debug in fact exist or not? In other words does it show up with \l in psql? Also it not necessary to use FULL with the VACUUM. Thanks in advance. Shailesh Singh -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Urgent Help Required
Adrian Klaver-3 wrote On 10/08/2013 03:55 AM, shailesh singh wrote: I had got this message while running vacuum full from backend . Now My database is not starting , Help pls. backend vacuum full debug; WARNING: database debug must be vacuumed within 99 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in debug. ERROR: relation debug does not exist Now what? First some information. 1) What version of Postgres are you using? 2) Does database debug in fact exist or not? In other words does it show up with \l in psql? Also it not necessary to use FULL with the VACUUM. Thanks in advance. Shailesh Singh From the documentation: http://www.postgresql.org/docs/9.2/interactive/sql-vacuum.html With no parameter, VACUUM processes every table in the current database that the current user has permission to vacuum. With a parameter, VACUUM processes only that table. Since you must be connected to a database to issue VACUUM to specify which database would be redundant. Your specification of debug in the above command was not taken to be a database but rather a relation/table. The basic steps are: 1) connect to the debug database. 2) issue the command VACUUM with no parameters The reason for the error is that transaction id wraparound is on the verge of occurring. After having solved the immediate problem by manually vacuuming you should try and describe to us why it is the auto-vacuum service has failed to vacuum the debug database in time to prevent the warning. The immediate solution will work on any version but the cause analysis will require knowing the PostgreSQL versions, its configuration, and basic usage characteristics. Regardless, though, always provide version information when asking for help. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Urgent-Help-Required-tp5773675p5773692.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Urgent Help Required
Dear all, First of all i wish to share actual error meassge, Below are the queries i had executed on the terminal on my server -bash-3.2$ touch fix.sql -bash-3.2$ echo VACUUM FULL; fix.sql -bash-3.2$ postgres -D /var/lib/pgsql/data patnadbold fix.sql WARNING: database patnadbold must be vacuumed within 100 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. WARNING: database patnadbold must be vacuumed within 100 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. PostgreSQL stand-alone backend 8.1.11 backend WARNING: database patnadbold must be vacuumed within 99 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. WARNING: database patnadbold must be vacuumed within 98 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. WARNING: database patnadbold must be vacuumed within 97 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. WARNING: database patnadbold must be vacuumed within 96 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. WARNING: database patnadbold must be vacuumed within 95 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. WARNING: database patnadbold must be vacuumed within 94 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. WARNING: database patnadbold must be vacuumed within 93 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. WARNING: database patnadbold must be vacuumed within 92 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. WARNING: database patnadbold must be vacuumed within 91 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. WARNING: database patnadbold must be vacuumed within 90 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. WARNING: database patnadbold must be vacuumed within 89 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. WARNING: database patnadbold must be vacuumed within 88 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. WARNING: database patnadbold must be vacuumed within 87 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. WARNING: database patnadbold must be vacuumed within 86 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. WARNING: database patnadbold must be vacuumed within 85 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. WARNING: database patnadbold must be vacuumed within 84 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. ERROR: could not access status of transaction 33011 DETAIL: could not open file pg_clog/: No such file or directory exit After this i am able to stop /start my db server but i am not able to connect to my databases (it tells to run vacuum full first on patnadbold databases) 1)I am using postgres 8.4 version. 2) I had two databases on this server i) patnadbold ii) patnaonlinedb For me patnadbold is of no use if at this moment i lost this database that also fine to me. I wanted to connect patnaonlinedb any how and wanted to perform backup of this , Solution please. On Tue, Oct 8, 2013 at 6:19 PM, Adrian Klaver adrian.kla...@gmail.comwrote: On 10/08/2013 03:55 AM, shailesh singh wrote: I had got this message while running vacuum full from backend . Now My database is not starting , Help pls. backend vacuum full debug; WARNING: database debug must be vacuumed within 99 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in debug. ERROR: relation debug does not exist Now what? First some information. 1) What version of Postgres are you using? 2) Does database debug in fact exist or not? In other words does it show up with \l in psql? Also it not necessary to use FULL with the VACUUM. Thanks in advance. Shailesh Singh -- Adrian Klaver adrian.kla...@gmail.com -- With Regards, शैलेश सिंह |Shailesh Singh +९१-९६५०३१७५१७ | +91-9650317517
Re: [GENERAL] Urgent Help Required
On 10/08/2013 08:03 AM, shailesh singh wrote: Dear all, First of all i wish to share actual error meassge, Below are the queries i had executed on the terminal on my server -bash-3.2$ touch fix.sql -bash-3.2$ echo VACUUM FULL; fix.sql -bash-3.2$ postgres -D /var/lib/pgsql/data patnadbold fix.sql WARNING: database patnadbold must be vacuumed within 100 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. WARNING: database patnadbold must be vacuumed within 100 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in patnadbold. PostgreSQL stand-alone backend 8.1.11 After this i am able to stop /start my db server but i am not able to connect to my databases (it tells to run vacuum full first on patnadbold databases) 1)I am using postgres 8.4 version. This seems to be at odds with PostgreSQL stand-alone backend 8.1.11. Are you sure you are working on the correct database cluster? 2) I had two databases on this server i) patnadbold ii) patnaonlinedb For me patnadbold is of no use if at this moment i lost this database that also fine to me. I wanted to connect patnaonlinedb any how and wanted to perform backup of this , Solution please. -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Urgent Help Required
postgres -D /var/lib/pgsql/data patnadbold fix.sql What the heck is the point of feeding VACUUM FULL; into the standard input of the postgres command? postgres simply starts the server, it does not execute arbitrary SQL. Once the database is started you want to use psql - either interactively or in a similar manner to the above - to connect to the patnadbold database and run VACUUM. Note that: su postgres - psql will likely connect you to the postgres database as that is the normal default. You will need to tell psql which database to connect to. PostgreSQL stand-alone backend 8.1.11 8.1 is unsupported at this point; plus you say 8.4 below which this contradicts. Your configuration is very unclear. ERROR: could not access status of transaction 33011 DETAIL: could not open file pg_clog/: No such file or directory exit This is bothersome as well... After this i am able to stop /start my db server but i am not able to connect to my databases (it tells to run vacuum full first on patnadbold databases) 1)I am using postgres 8.4 version. 2) I had two databases on this server i) patnadbold ii) patnaonlinedb For me patnadbold is of no use if at this moment i lost this database that also fine to me. I wanted to connect patnaonlinedb any how and wanted to perform backup of this , Solution please. The only thing not mentioned is starting postgres is single-user mode; this may be necessary though I am not sure and others can be of more help. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Urgent-Help-Required-tp5773675p5773716.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Urgent Help Required
On 10/08/2013 09:03 AM, David Johnston wrote: postgres -D /var/lib/pgsql/data patnadbold fix.sql What the heck is the point of feeding VACUUM FULL; into the standard input of the postgres command? postgres simply starts the server, it does not execute arbitrary SQL. Once the database is started you want to use psql - either interactively or in a similar manner to the above - to connect to the patnadbold database and run VACUUM. I was under that impression also. So I went back in the archives, and in 8.1 this was possible. http://www.postgresql.org/docs/8.1/interactive/app-postgres.html PostgreSQL stand-alone backend 8.1.11 8.1 is unsupported at this point; plus you say 8.4 below which this contradicts. Your configuration is very unclear. This part is still unclear to me. I would like some more information on where the 8.4 cluster comes into play, if at all. My hunch is the OP is working with two different Postgres instances un-intently . David J. -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Urgent Help required
On Fri, Oct 16, 2009 at 11:26 AM, Neha Patel npa...@nevi-soft.com wrote: Hi, We are running with postgres sql 7.3.2. We were trying to create an index on a big table. The create index command ran for nearly 5 hours at which point we decided to interrupt it. Since this was interrupted, any operations attempted on the table on which the index was being created gives following error in pgsql log: upgrade to whatever is the newest 7.3.X version now first, and also - 7.3 is an ancient history - in terms of age, so you might wanna look at upgrading to 8.3 or newer soon. LOG: all server processes terminated; reinitializing shared memory and semaphor es LOG: database system was interrupted at 2009-10-16 10:44:54 BST LOG: checkpoint record is at 150/71A0C0CC LOG: redo record is at 150/71A0C0CC; undo record is at 0/0; shutdown TRUE LOG: next transaction id: 1757299460; next oid: 43508941 LOG: database system was not properly shut down; automatic recovery in progress LOG: ReadRecord: record with zero length at 150/71A0C10C LOG: redo is not required LOG: database system is ready Any idea what this means and what we need to do to resolve access to this table again? We can see the next oid number increases over time. Access to all other tables in the database is fine. Any help would be greatly appreciated. Many Thanks *Neha.* -- GJ
Re: [GENERAL] Urgent Help required
On Fri, Oct 16, 2009 at 11:26:40AM +0100, Neha Patel wrote: Hi, We are running with postgres sql 7.3.2. Whatever you thought your most urgent priority was, it's actually getting your database off of a major version of PostgreSQL, 7.3, whose end-of-life was well over a year ago. Your second most urgent priority is creating an upgrade strategy and integrating it into your development and deployment processes. I hope you have good backups. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Urgent Help required
Hi David, Many thanks for your reply. After good 10 hours of work we managed to restore from a backup. Regards Neha -Original Message- From: David Fetter [mailto:da...@fetter.org] Sent: 16 October 2009 17:28 To: Neha Patel Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] Urgent Help required On Fri, Oct 16, 2009 at 11:26:40AM +0100, Neha Patel wrote: Hi, We are running with postgres sql 7.3.2. Whatever you thought your most urgent priority was, it's actually getting your database off of a major version of PostgreSQL, 7.3, whose end-of-life was well over a year ago. Your second most urgent priority is creating an upgrade strategy and integrating it into your development and deployment processes. I hope you have good backups. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Urgent Help required
Neha Patel wrote: Hi, We are running with postgres sql 7.3.2. We were trying to... well, right off the bat, thats a -really- old version. Release notes say February 2003. 7.3 was updated to 7.3.21, and we're currently on 8.4 (while still supporting 8.3, 8.2, 8.1, and 7.4).There were a LOT of fixes between 7.3.2 and 7.3.21, see the release notes for each version in between... http://www.postgresql.org/docs/current/static/release.html -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Urgent Help required
On Fri, 2009-10-16 at 11:26 +0100, Neha Patel wrote: We are running with postgres sql 7.3.2. We were trying to create an index on a big table. The create index command ran for nearly 5 hours at which point we decided to interrupt it. Since this was interrupted, any operations attempted on the table on which the index was being created gives following error in pgsql log: LOG: all server processes terminated; reinitializing shared memory and semaphor 1. Shut down postgresql and make a full filesystem copy of the PGDATA directory. This will ensure that anything else you do won't leave you in a worse position. 2. Upgrade to the latest version of postgresql 7.3, which is 7.3.21 3. Start up again 4. Try to fix the problem: a. see if there are any indexes on the table b. if so, drop them c. try to get a good logical backup using pg_dump. You may want to disable index scans by using SET enable_indexscan = f;. d. If that doesn't work, you may have catalog corruption. Examine the catalogs (documented here: http://www.postgresql.org/docs/7.3/static/catalogs.html ), and look entries related to your table in pg_class and pg_index, and see if anything looks wrong. e. start from a fresh install and restore using the logical backup 5. Upgrade all data to a recent version of postgresql. You're on a really ancient version that has fallen out of official support. This may require several upgrade steps, but you should get upgraded to 8.3.8 or 8.4.1. A lot of bugs have been fixed, and as long as you are on 7.3, you will still be at serious risk. Regards, Jeff Davis -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Urgent Help required
Hmm would this be a bad time to ask for PostGres 1.0 support? On Fri, Oct 16, 2009 at 1:55 PM, Jeff Davis pg...@j-davis.com wrote: On Fri, 2009-10-16 at 11:26 +0100, Neha Patel wrote: We are running with postgres sql 7.3.2. We were trying to create an index on a big table. The create index command ran for nearly 5 hours at which point we decided to interrupt it. Since this was interrupted, any operations attempted on the table on which the index was being created gives following error in pgsql log: LOG: all server processes terminated; reinitializing shared memory and semaphor 1. Shut down postgresql and make a full filesystem copy of the PGDATA directory. This will ensure that anything else you do won't leave you in a worse position. 2. Upgrade to the latest version of postgresql 7.3, which is 7.3.21 3. Start up again 4. Try to fix the problem: a. see if there are any indexes on the table b. if so, drop them c. try to get a good logical backup using pg_dump. You may want to disable index scans by using SET enable_indexscan = f;. d. If that doesn't work, you may have catalog corruption. Examine the catalogs (documented here: http://www.postgresql.org/docs/7.3/static/catalogs.html ), and look entries related to your table in pg_class and pg_index, and see if anything looks wrong. e. start from a fresh install and restore using the logical backup 5. Upgrade all data to a recent version of postgresql. You're on a really ancient version that has fallen out of official support. This may require several upgrade steps, but you should get upgraded to 8.3.8 or 8.4.1. A lot of bugs have been fixed, and as long as you are on 7.3, you will still be at serious risk. Regards, Jeff Davis -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
