[GENERAL] pg_dump fails pg_rewrite entry not found
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? 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 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
[GENERAL] pg_dump fails when it gets to table containing bytea
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 name 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;
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 database 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 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 name 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 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
[GENERAL] pg_dump fails on 7.4 Postgres
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
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
audit(1115732852.028:0): avc: denied { search } for pid=11023
exe=/usr/bin/pg_dump name=/ dev=sda3 ino=2
scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:file_t
tclass=dir
[ ~]$
Here's Postgres rpm on the machine in question:
[~]$ rpm -qa | egrep postgres
postgresql-tcl-7.4.6-1.RHEL4.2
postgresql-pl-7.4.6-1.RHEL4.2
postgresql-docs-7.4.6-1.RHEL4.2
postgresql-odbc-7.3-8
postgresql-7.4.6-1.RHEL4.2
postgresql-server-7.4.6-1.RHEL4.2
postgresql-test-7.4.6-1.RHEL4.2
postgresql-libs-7.4.6-1.RHEL4.2
postgresql-jdbc-7.4.6-1.RHEL4.2
postgresql-python-7.4.6-1.RHEL4.2
postgresql-contrib-7.4.6-1.RHEL4.2
postgresql-devel-7.4.6-1.RHEL4.2
[~]$
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
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 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
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
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
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
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
[GENERAL] pg_dump fails
I'm running postgresql 7.4.7 on x86 and have run into a problem trying to export my database. When I use pg_dump --file=stats.out --format=t printstats, (and I may have the syntax wrong), I get this error: pg_dump: SQL command failed 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' I tried googling for an answer, and found a couple of references to this error, but nothing that could help me. Can anyone help me out here? Thanks 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
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
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: 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
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 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 (bunch of columns 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
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 (bunch of columns 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: 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
[GENERAL] pg_dump fails with socket_not_open
Hi there folks, 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 (bunch of columns TO stdout Are there any common reasons for seeing this? I'm fairly sure that the machine is ok hardware wise - any pointers appreciated. Thanks, Sarah. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[GENERAL] pg_dump fails with socket_not_open
Hi there folks, 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 (bunch of columns TO stdout Are there any common reasons for seeing this? I'm fairly sure that the machine is ok hardware wise, and strangely enough, pg_dumpall works, so it's really curiosity and to set my mind at rest - any pointers appreciated. Thanks, Sarah. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
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 (bunch of columns 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]
[GENERAL] pg_dump fails, data integrity imperfect
At some point between april 13 and now a single row in my 'orders' table became compromised and caused the failure of pg_dump upon which I had been depending for a backup, sort of. I say sort of because I allowed each days dump to overwrite the previous and as such cannot point to a specific day and say that's when it came unstuck. Upon deletion of the afflicted row the pg_dump proceeded in an orderly manner. Is there any obvious/common cause of corruption of (probably varchar) data? Is there any simple/automated detection scheme? The database is on RedHat 6.1 linux box with a paltry 64 megs of ram to entertain its celeron 333. The dbase version is postgres 6.5.3 . The whole kit is about to be upgraded to RedHat7.1/Postgres7.03 128Meg 533Mhz. [postgres@midas pgsql]$ pg_dump belladata/sunday.dump FATAL 1: Memory exhausted in AllocSetAlloc() PQendcopy: resetting connection SQL query to dump the contents of Table 'orders' did not execute correctly. After we read all the table contents from the backend, PQendcopy() failed. Explanation from backend: 'FATAL 1: Memory exhausted in AllocSetAlloc() '. The query was: 'COPY orders TO stdout; '. [postgres@midas pgsql]$ This is the last few lines that the dump output. I have seperated individual orders with a blank line for clarity 16997 1 Fri Dec 15 16:37:12 2000 PSTt Cash$2.94 $0.19 $0.00 1 Regular SLC VEG $2.75! ! !ISPEC!* COMPLETEPickup f 716736777 16998 9802215 Fri Dec 15 16:43:21 2000 PSTf Cash$20.38 $1.33 $0.00 1 Medium HAW $12.25! ! !0 0 1 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1ISPEC!*2 Small T.S. $3.00! ! !ISPEC!*4 Regular G.B. $3.80! ! !ISPEC!*COMPLETEDeliveryf 716736777 16999 9908055 Fri Dec 15 16:45:12 2000 PSTf Cash$17.92 $1.17 $0.00 1 Regular WH CHICK $9.75! ! !0 0 0 1ISPEC!*1 Regular L.M.S. $7.00! ! !ISPEC!* COMPLETEDeliveryf 716736777 17000 9855620 Fri Dec 15 16:48:15 2000 PSTf Cash$20.60 $1.35 $0.00 1 Small BASIC $6.25! ! !0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0ISPEC!*1 Small GOURMET $10.50! ! !0 1 0 0 0 1 0 1 0 1 0 0 0 0 0 0 1 0 0 1 0 0 0 1 1 0 0 0 0 0 0 1ISPEC!*2 Regular Pop $2.50!2x R.B.! !0 0 0 0 0 0 2ISPEC!* COMPLETE Deliveryf 716736777 17225 1 Sun Dec 17 01:45:29 2000 PSTt Cash$2.94 $0.19 $0.00 447 19688 19I! 8 19I! f Here's the 'wounded' ordernumber as queried from a previously dumped version bella=# select * from orders where ordnumber=17225; ordnumber | customernumber | ordertime| pickupdel | paymethod | total | gstotal | discount | items | status | pudelcharge | edits | wastecolumn | staff ---+++---+---+---+-+--+---+--+-+---+-+--- 17225 | 1 | 2000-12-17 01:45:29-08 | t | Cash | $2.94 | $0.19 |$0.00 | 1 Regular SLC VEG $2.75! ! !ISPEC!* | COMPLETE | Pickup | f | | 716736777 (1 row) -- Glenn Wittrock Linux: when you need to run like a greased weasel. ---(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
[GENERAL] pg_dump fails sanity check
Using version 7.0.2 (system is production, so I can't take it down for minor releases) I enter: $ pg_dump romanlegion rdb.backup and I get: failed sanity check, table usergames was not found Ok, fair enough, so: $ psql romanlegion romanlegion=# \d usergames Table "usergames" Attribute | Type | Modifier +-+-- gameuserid | integer | not null gameplayed | integer | not null Index: unique_played romanlegion=# select * from usergames ; gameuserid | gameplayed + 10 | 1 snip 442 | 10 (477 rows) romanlegion=# Now, it can find the table, describe the table, select from the table, and the more complex queries I do on the site work just fine also. I can make sure it is where I expect it to be. $ su postgres Password: $ ls /var/lib/pgsql/data/base/romanlegion/usergames -al -rw--- 1 postgres postgres40960 Jan 25 23:43 /var/lib/pgsql/data/base/romanlegion/usergames So now I'm out of ideas. Is there some known bug? Or is this just being weird?
