Re: [GENERAL] pg_dump fails pg_rewrite entry not found
I am terribly sorry. I was sinked in this for about 2 days and just a few minutes after i posted this a was told by a 3rd person that I am using datbase postgres instead of eb3_nz to searched for pending OID in pg_rewrite. So the common delete from pg_rewrite where oid = 1001837 worked. Thanks a lot. On 03/14/2014 03:11 PM, Adrian Klaver wrote: > On 03/14/2014 06:56 AM, Jakub Can wrote: >> Hello, our database suddenly went broken somehow. We still dont know if >> it is becouse of hw failure etc., anyway, when I try to make dump using >> pg_dump or pg_dumpall I have got error message like this: >> >> pg_dump: failed sanity check, parent table OID 1001834 of pg_rewrite >> entry OID 1001837 not found >> pg_dumpall: pg_dump failed on database "eb3_nz", exiting >> >> I have tried to search for such an error and have found a lot of >> solution suggestions, but nothing worked for me, because I did not found >> any record in pg_class, or pg_rewrite, etc. referencing to those OIDs >> 1001834 or 1001837 . The version of postgres is 9.2.2 >> >> Please is there any other place, where to look for the error? > > So 'select * from pg_rewrite where oid = 1001837' finds nothing? > >> >> Thank you in advance, >> Jakub. >> >> > > -- 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] pg_dump fails pg_rewrite entry not found
On 03/14/2014 06:56 AM, Jakub Can wrote: Hello, our database suddenly went broken somehow. We still dont know if it is becouse of hw failure etc., anyway, when I try to make dump using pg_dump or pg_dumpall I have got error message like this: pg_dump: failed sanity check, parent table OID 1001834 of pg_rewrite entry OID 1001837 not found pg_dumpall: pg_dump failed on database "eb3_nz", exiting I have tried to search for such an error and have found a lot of solution suggestions, but nothing worked for me, because I did not found any record in pg_class, or pg_rewrite, etc. referencing to those OIDs 1001834 or 1001837 . The version of postgres is 9.2.2 Please is there any other place, where to look for the error? So 'select * from pg_rewrite where oid = 1001837' finds nothing? Thank you in advance, Jakub. -- Adrian Klaver adrian.kla...@aklaver.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] pg_dump fails when it gets to table containing bytea
Is your table really named "blob" ??? You said it fails when it gets to the table named "blob" not somewhere in the process of dumping the table "blob"... There might be a clue in that... What happens if yo rename the table to something other than an SQL reserverd word ? Although postgreSQL doesn't have a data type of "blob" (many other RDBMS's do, including blob and clob), there's a chance that the word "blob" is used internally by postgreSQL for historical purposes >From section 8.1 (Data Types) of the manual there is a possibility that "blob" is an alias used internally by postgreSQL Table 8.1, "Data Types" shows all built-in general-purpose data types. Most of the alternative names listed in the "Aliases" column are the names used internally by PostgreSQL for historical reasons. In addition, some internally used or deprecated types are available, but they are not listed here. ""Carlos Oliva"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Could anyone suggest something that we can check to ascertain why pg_dumps fail? The pg_dump for our database just started to fail this week. Dumps of the same database succeeded just last week. Moreover, we can create a new database using the database (that we are trying to dump) as a template and the data is copied into the new database. We are getting the following error message whe we run "pg_dump -Ft > database.tar": pg_dump: ERROR: canceling query due to user request pg_dump: SQL command to dump the contents of table "blob" failed: PQendcopy() fa iled. pg_dump: Error message from server: ERROR: canceling query due to user request pg_dump: The command was: COPY public.blob (prtnbr, bkey, bdsc, btypnbr, bcrtdte , bcrttme, bcrtusr, bflepath, bflenam, bfleext, bsetnbr, cblob) TO stdout; ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] pg_dump fails when it gets to table containing bytea
"Carlos Oliva" <[EMAIL PROTECTED]> writes: > We are getting the following error message whe we run "pg_dump -Ft name> > database.tar": > pg_dump: ERROR: canceling query due to user request This implies that something sent SIGINT to the backend process. We've heard some reports that suggest that some platforms send SIGINT when a soft resource consumption limit is hit (too much process runtime or I/O or something). Look around for something of that description, particularly if the limit settings were changed recently. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] pg_dump fails on 7.4 Postgres
Tom Lane wrote: "Jimmie H. Apsey" <[EMAIL PROTECTED]> writes: At this point, I am unable to do a pg_dump using our new Rec Hat Enterprise Linux AS 4 version of Postgres which is version 7.4. Here's what I get when I try to do a pg_dump of our database: [ ~]$ /usr/bin/pg_dump dcf_20050404 >& /~/dcf_20050404_`date +%y%m%d`.dmp audit(1115732852.025:0): avc: denied { write } for pid=11023 exe=/usr/bin/pg_dump path=/~/dcf_20050404_050510.dmp dev=sda3 ino=5522308 scontext=user_u:system_r:postgresql_t tcontext=user_u:object_r:file_t tclass=file Hmm, what is the SELinuxWe disabled the SELinux protection for the postgres deamon and were able to successfully run pg_dump on our new Red Hat Enterprise Linux AS 4 postgres. Do you have any opinion about this 'fix'? Jim Apsey labeling for pg_dump? Try $ ls -Z /usr/bin/pg_dump -rwxr-xr-x root root system_u:object_r:bin_t /usr/bin/pg_dump If you get something other than that, try "/sbin/restorecon -R /usr/bin" as root; if that doesn't fix it, you probably need to update your SELinux policy (RPM selinux-policy-targeted). I am not entirely sure whether a policy RPM update automatically does the equivalent of "/sbin/restorecon -R /", but if you don't see the right context after an update, that's what I'd suggest. Here's Postgres rpm on the machine in question: postgresql-7.4.6-1.RHEL4.2 postgresql-server-7.4.6-1.RHEL4.2 I think that was what went out on the RHEL4 CD-ROMs, but why aren't you running up2date? There are serious known bugs in that version. If you're paying Red Hat for support, you should be using that support ;-) regards, tom lane Thank you once again Tom Lane. We disabled the SELinux protection for the postgres daemon and were able to successfully run pg_dump on our new Red Hat Enterprise Linux AS 4 postgres. Do you have any opinion about this 'fix'? We have hired a Linux professional and he installed AS 4 on our new Dell Server. I don't know how we keep things up-to-date with up2date anymore. Jim Apsey ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] pg_dump fails on 7.4 Postgres
"Jimmie H. Apsey" <[EMAIL PROTECTED]> writes: > At this point, I am unable to do a pg_dump using our new Rec Hat > Enterprise Linux AS 4 version of Postgres which is version 7.4. > Here's what I get when I try to do a pg_dump of our database: > [ ~]$ /usr/bin/pg_dump dcf_20050404 >& /~/dcf_20050404_`date +%y%m%d`.dmp > audit(1115732852.025:0): avc: denied { write } for pid=11023 > exe=/usr/bin/pg_dump path=/~/dcf_20050404_050510.dmp > dev=sda3 ino=5522308 scontext=user_u:system_r:postgresql_t > tcontext=user_u:object_r:file_t tclass=file Hmm, what is the SELinux labeling for pg_dump? Try $ ls -Z /usr/bin/pg_dump -rwxr-xr-x root root system_u:object_r:bin_t /usr/bin/pg_dump If you get something other than that, try "/sbin/restorecon -R /usr/bin" as root; if that doesn't fix it, you probably need to update your SELinux policy (RPM selinux-policy-targeted). I am not entirely sure whether a policy RPM update automatically does the equivalent of "/sbin/restorecon -R /", but if you don't see the right context after an update, that's what I'd suggest. > Here's Postgres rpm on the machine in question: > postgresql-7.4.6-1.RHEL4.2 > postgresql-server-7.4.6-1.RHEL4.2 I think that was what went out on the RHEL4 CD-ROMs, but why aren't you running up2date? There are serious known bugs in that version. If you're paying Red Hat for support, you should be using that support ;-) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] pg_dump fails on 7.4 Postgres
"Jimmie H. Apsey" <[EMAIL PROTECTED]> writes: > This may be my second posting but I think I've done it correctly this time. > At this point, I am unable to do a pg_dump using our new Rec Hat > Enterprise Linux AS 4 version of Postgres which is version 7.4. > Here's what I get when I try to do a pg_dump of our database: > --- > [~]$ > [ ~]$ /usr/bin/pg_dump dcf_20050404 >& /~/dcf_20050404_`date +%y%m%d`.dmp > audit(1115732852.025:0): avc: denied { write } for pid=11023 > exe=/usr/bin/pg_dump path=/~/dcf_20050404_050510.dmp > dev=sda3 ino=5522308 scontext=user_u:system_r:postgresql_t > tcontext=user_u:object_r:file_t tclass=file Looks like your security settings aren't allowing pg_dump to write files. You should probably talk to Red Hat about how to fix them. -Doug ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] pg_dump fails
What I was trying to do was export the database on one computer and import it onto another. I gave up trying to fix the export problem since I had an old backup of the database. It was old enough that it was short three tables, but I have the raw tab delimited data so I just reconstructed the database on this new machine. I've been running Gentoo for about a year and a half now, and in the early days, I did not fully understand all of the possible USE settings, but I've gotten more comfortable with it over time. As you probably know, once you've settled on what your USE settings should be, you can rebuild your system to reflect those new settings. I did that, and since everything appeared to be working OK, I assumed everything was OK, but obviously the damage to PostgreSQL was already done. Anyway, I think my settings now are pretty conservative and I know ot to play around with the Postgres USE flags. One of the reasons I'm migrating is to do a complete rebuild and apply what I've learned about Gentoo from scratch on a new computer. Here are my settings, as you asked. I don't think they're too out of line, but... On Apr 19, 2005, at 6:06 p, Russell Smith wrote: I read your post in the forums. And as Tom suggested, it's going nothing to do with pg_dump, you need to remerge postgresql at the very least, and with some C and USE flags you understand. The Usual Gentoo causes come to mind first. USE flags set correctly? what are they? USE="X -gnome -gtk -gtk2 cups -kde -qt What are your GCC flags. I see a lot of gentoo users who just about turn on every compiler flag without actually knowing what they do, or how they effect things. Are your C_FLAGS conservative? CFLAGS="-O2 -mtune=G3 -fno-strict-aliasing -pipe" I've been using Postgresql on gentoo for both 7.4, and 8.0 from beta to 8.0.2 with no problems. But then I always set my C_FLAGS to something conservative like CGLAGS="-march=i586 -mcpu=i586 -O2 -pipe" yes, it may seems a "Gentoo Conservative" buy I don't get broken software. Always check extra patches applied to the default distribution if you ever have trouble to weed out problem. And never build with and USE flags you don't understand the implications of. Especially package specific ones. I've always been a bit concerned about the patches myself. I understand Tom's frustration, as Redhat is in business and ships quality checked software, and Gentoo is run by a community group. Of which I think may of the packagers are not tied to the projects they are packaging. But I also think there is often fault with the Gentoo user attempting to bleed his system a little too much for speed, without considering the stability or even understand it. "My Break-Dancing days are over, but there's always the Funky Chicken" --The Full Monty
Re: [GENERAL] pg_dump fails
On Tue, 19 Apr 2005 11:53 pm, Lorenzo Thurman wrote: > Thanks for the reply. I've tried recompiling with my install build > settings, but no luck. I've posted a message on the Gentoo forums. > Hopefully they will have an answer. If they do, I'll post back here for > future reference. > I read your post in the forums. And as Tom suggested, it's going nothing to do with pg_dump, you need to remerge postgresql at the very least, and with some C and USE flags you understand. The Usual Gentoo causes come to mind first. USE flags set correctly? what are they? What are your GCC flags. I see a lot of gentoo users who just about turn on every compiler flag without actually knowing what they do, or how they effect things. Are your C_FLAGS conservative? I've been using Postgresql on gentoo for both 7.4, and 8.0 from beta to 8.0.2 with no problems. But then I always set my C_FLAGS to something conservative like CGLAGS="-march=i586 -mcpu=i586 -O2 -pipe" yes, it may seems a "Gentoo Conservative" buy I don't get broken software. Always check extra patches applied to the default distribution if you ever have trouble to weed out problem. And never build with and USE flags you don't understand the implications of. Especially package specific ones. I understand Tom's frustration, as Redhat is in business and ships quality checked software, and Gentoo is run by a community group. Of which I think may of the packagers are not tied to the projects they are packaging. But I also think there is often fault with the Gentoo user attempting to bleed his system a little too much for speed, without considering the stability or even understand it. Regards Russell Smith. > On Apr 19, 2005, at 1:01 AM, Tom Lane wrote: > > > Lorenzo Thurman <[EMAIL PROTECTED]> writes: > >> I'm trying that right now. I think there may be mis-match in the build > >> settings between upgrades of postgresql. The "USE" settings may be at > >> fault: > > > >> - - pg-hier: Enables recursive queries like Oracle's > >> 'CONNECT > >> BY' feature. > > > > [ rolls eyes... ] Yup, that's Gentoo all right: throw in random > > patches > > that have been rejected by the upstream developers. Now that I think > > about it, this failure is exactly what that patch is known to cause, > > because it makes an incompatible change in Query structures and hence > > in on-disk view rule representation. > > > >> I think these may have been changed since the original install. > > > > Go back to your prior setting, or even better stop using Gentoo's > > hacked-up version. I'm not sure why we even bother to answer support > > requests from Gentoo users, when what they are using is not our > > software but some randomly-modified variant. I wonder what other > > brokennesses Gentoo may be including ... > > > > (Just for the record: I work for Red Hat, which has a rather different > > notion of the level of reliability it wants to ship. So take my > > opinion > > with the appropriate grain of salt. But I'm a mite ticked off at the > > moment --- you're not the first person to have been bitten by this, > > and you likely won't be the last, and I think it's entirely because > > Gentoo has such a low quality standard for the patches they ship.) > > > >regards, tom lane > > > > > > > Tech/Library Combo Lab Manager > Northwestern University > Office Tech MG49 > mailto:[EMAIL PROTECTED] > voice: 847-467-6565 > pager: 847-536-0094 > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org > > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] pg_dump fails
Thanks for the reply. I've tried recompiling with my install build settings, but no luck. I've posted a message on the Gentoo forums. Hopefully they will have an answer. If they do, I'll post back here for future reference. On Apr 19, 2005, at 1:01 AM, Tom Lane wrote: Lorenzo Thurman <[EMAIL PROTECTED]> writes: I'm trying that right now. I think there may be mis-match in the build settings between upgrades of postgresql. The "USE" settings may be at fault: - - pg-hier: Enables recursive queries like Oracle's 'CONNECT BY' feature. [ rolls eyes... ] Yup, that's Gentoo all right: throw in random patches that have been rejected by the upstream developers. Now that I think about it, this failure is exactly what that patch is known to cause, because it makes an incompatible change in Query structures and hence in on-disk view rule representation. I think these may have been changed since the original install. Go back to your prior setting, or even better stop using Gentoo's hacked-up version. I'm not sure why we even bother to answer support requests from Gentoo users, when what they are using is not our software but some randomly-modified variant. I wonder what other brokennesses Gentoo may be including ... (Just for the record: I work for Red Hat, which has a rather different notion of the level of reliability it wants to ship. So take my opinion with the appropriate grain of salt. But I'm a mite ticked off at the moment --- you're not the first person to have been bitten by this, and you likely won't be the last, and I think it's entirely because Gentoo has such a low quality standard for the patches they ship.) regards, tom lane Tech/Library Combo Lab Manager Northwestern University Office Tech MG49 mailto:[EMAIL PROTECTED] voice: 847-467-6565 pager: 847-536-0094 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] pg_dump fails
Lorenzo Thurman <[EMAIL PROTECTED]> writes: > I'm trying that right now. I think there may be mis-match in the build > settings between upgrades of postgresql. The "USE" settings may be at > fault: > - - pg-hier: Enables recursive queries like Oracle's 'CONNECT > BY' feature. [ rolls eyes... ] Yup, that's Gentoo all right: throw in random patches that have been rejected by the upstream developers. Now that I think about it, this failure is exactly what that patch is known to cause, because it makes an incompatible change in Query structures and hence in on-disk view rule representation. > I think these may have been changed since the original install. Go back to your prior setting, or even better stop using Gentoo's hacked-up version. I'm not sure why we even bother to answer support requests from Gentoo users, when what they are using is not our software but some randomly-modified variant. I wonder what other brokennesses Gentoo may be including ... (Just for the record: I work for Red Hat, which has a rather different notion of the level of reliability it wants to ship. So take my opinion with the appropriate grain of salt. But I'm a mite ticked off at the moment --- you're not the first person to have been bitten by this, and you likely won't be the last, and I think it's entirely because Gentoo has such a low quality standard for the patches they ship.) regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] pg_dump fails
I'm trying that right now. I think there may be mis-match in the build settings between upgrades of postgresql. The "USE" settings may be at fault: - - pg-hier: Enables recursive queries like Oracle's 'CONNECT BY' feature. - - pg-vacuumdelay : Adds in the vacuum inter-page delay feature. - - pg-intdatetime : Enables --enable-integer-datetimes configure option, which changes PG to use 64-bit integers for timestamp storage I think these may have been changed since the original install. On Apr 18, 2005, at 11:57 p, Tom Lane wrote: Lorenzo Thurman <[EMAIL PROTECTED]> writes: ERROR: did not find '}' at end of input node I installed this from Gento's portage repository. Gentoo has a history of supplying broken compilers, software, etc ... bleeding edge stuff tends to cut you occasionally :-( You might try updating your compiler and then rebuilding PG. regards, tom lane I got an object I was sure it was point ClassCastException -- Jens Alfke
Re: [GENERAL] pg_dump fails
Lorenzo Thurman <[EMAIL PROTECTED]> writes: >>> ERROR: did not find '}' at end of input node > I installed this from Gento's portage repository. Gentoo has a history of supplying broken compilers, software, etc ... bleeding edge stuff tends to cut you occasionally :-( You might try updating your compiler and then rebuilding PG. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] pg_dump fails
On Apr 18, 2005, at 4:46 p, Tom Lane wrote: Also, does "select * from pg_user" provoke the same error in every database of your installation, or only this one? If the latter, it could be a data-corruption kind of problem. I only have one database right now. When I try "select * from pg_user", I get this error: ERROR: did not find '}' at end of input node I installed this from Gento's portage repository. "There are 10 types of people in this world: those who understand binary, those who don't" --Unknown
Re: [GENERAL] pg_dump fails
Lorenzo Thurman <[EMAIL PROTECTED]> writes: > pg_dump: Error message from server: ERROR: did not find '}' at end of > input node > pg_dump: The command was: SELECT (SELECT usename FROM pg_user WHERE > usesysid = datdba) as dba, pg_encoding_to_char(encoding) as encoding, > datpath FROM pg_database WHERE datname = 'printstats' This suggests that there's something wrong with the pg_user view --- specifically, that the stored view rule isn't in the format that the backend expects. I don't recall ever having seen that error in the field, only in development builds that someone had been sloppy about fully rebuilding after a CVS update (so that the code inside the server wasn't fully self-consistent). Where did you get your postgres executable from, exactly? Also, does "select * from pg_user" provoke the same error in every database of your installation, or only this one? If the latter, it could be a data-corruption kind of problem. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] pg_dump fails with socket_not_open
> "SE" == Sarah Ewen <[EMAIL PROTECTED]> writes: SE> Hi there folks, SE> I've just had pg_dump fail on me for the first time ever, and I'm not SE> sure why. SE> It generates 24MB of dump before bombing out with: SE> pg_dump: socket not open SE> pg_dump: SQL command to dump the contents of table "activity_log" SE> failed: PQendcopy() failed. SE> pg_dump: Error message from server: socket not open SE> pg_dump: The command was: COPY public.activity_log ( SE> TO stdout Funny I just saw this for the very first time *ever* as well, overnight. I was dumping from a PG 8.0.1 server to PG 8.0.1 client. I, however, saw some ethernet interface timeouts in my server logs, which is very concerning to me. So it probably wasn't PG's fault, but I'm not ruling anything out just yet... i do see a bunch of socket not open errors for some reporting clients with no corresponding ethernet timeouts, so the log information is either conflicting or incomplete. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: khera@kciLink.com Rockville, MD +1-301-869-4449 x806 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] pg_dump fails with socket_not_open
Sarah Ewen <[EMAIL PROTECTED]> writes: >> Is this repeatable? What shows up in the postmaster's log when it >> happens? What platform is this on, and what version of Postgres? > This is postgresql-7.4.6-1.FC2.2 running on RedHat Fedora Core 2. > The logs don't reveal anything, and it happens consistently! The 7.4 RPMs' startup script sends the postmaster stderr to /dev/null :-(. To find out what the server sees as the problem, you need to either hack the startup script to send stderr someplace more useful, or adjust the configuration to send the postmaster's log messages to syslog. I would recommend doing one or the other since it's quite likely that the server-side view of the problem is different from what the client sees. > It is a little disconcerting..by the sounds of things this is a fairly > rare thing to see? Yes. I would like to get to the bottom of it. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] pg_dump fails with socket_not_open
Hi there Tom, thanks for your reply. pg_dump: socket not open pg_dump: SQL command to dump the contents of table "activity_log" failed: PQendcopy() failed. pg_dump: Error message from server: socket not open pg_dump: The command was: COPY public.activity_log ( TO stdout Is this repeatable? What shows up in the postmaster's log when it happens? What platform is this on, and what version of Postgres? This is postgresql-7.4.6-1.FC2.2 running on RedHat Fedora Core 2. The logs don't reveal anything, and it happens consistently! It is a little disconcerting..by the sounds of things this is a fairly rare thing to see? Sarah. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] pg_dump fails with socket_not_open
Sarah Ewen <[EMAIL PROTECTED]> writes: > I've just had pg_dump fail on me for the first time ever, and I'm not > sure why. > It generates 24MB of dump before bombing out with: > pg_dump: socket not open > pg_dump: SQL command to dump the contents of table "activity_log" > failed: PQendcopy() failed. > pg_dump: Error message from server: socket not open > pg_dump: The command was: COPY public.activity_log ( > TO stdout Is this repeatable? What shows up in the postmaster's log when it happens? What platform is this on, and what version of Postgres? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]