Thread: >>relation with OID 1211822032 does not exist
Hi All,
We are getting following error on intermittent basis when we write data into database. We are on postgreSQL 8.0.2, with slony I. We used to stop the replication, taking back-up from the primary, restore it on secondary server and again start the replication again. We used to do above activity once in a month. After re-starting the replication last time we are getting this error.
We have checked at database side but didn't find much to solve this error. Can somebody point us where we can look for. We have found following from the logs.
ERROR: P0001: usr(): Password provided not equal to stored password.
ERROR: P0001: usr(): Password provided not equal to stored password.
ERROR: 22004: cannot EXECUTE a null querystring
ERROR: 42P01: relation "sl_confirm" does not exist
ERROR: 42P01: relation "sl_confirm" does not exist
ERROR: relation with OID 1211822032 does not exist
--
Thanks
Dj
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon,this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from your computer. Microland takes all reasonable steps to ensure that its electronic communications are free from viruses. However, given Internet accessibility, the Company cannot accept liability for any virus introduced by this e-mail or any attachment and you are advised to use up-to-date virus checking software.
On 8/06/2010 8:25 PM, Jaiswal Dhaval Sudhirkumar wrote: > Hi All, > > We are getting following error on intermittent basis when we write data > into database. We are on postgreSQL 8.0.2 While this doesn't help you track down your problem directly ... 8.0.2? Really? Version 8.0 is up to patch level 25 (!!) so you're missing out on a LOT of bug fixes. 8.0 needed plenty of them, too :S Anyway, first I strongly recommend that you try to pg_dumpall and make sure you keep that dump somewhere other than the problem machine. Next, I'd look at whether that report could be coming from a stored procedure that hadn't been re-loaded after a table/view/proc that it uses changed. Before 8.3, stored procedures had to be reloaded after such changes (and didn't work quite right with temp tables, either). Then I'd turn up the log level and detail, and see if I could find out what statement was triggering the error report. -- Craig Ringer