agora inbox for pgsql-general@postgresql.org
help / color / mirror / Atom feedpg_dump problems
20+ messages / 9 participants
[nested] [flat]
* pg_dump problems
@ 2000-09-27 20:25 Michelle Murrain <mpm@norwottuck.com>
0 siblings, 1 reply; 20+ messages in thread
From: Michelle Murrain @ 2000-09-27 20:25 UTC (permalink / raw)
To: pgsql-general
In doing a pg_dump on a relatively new Postgres install, I get an
error I've never seen before:
getInherits():SELECT failed. Explanation from backend:
'ERROR:Attribute 'inhre1' not found.'
The dump didn't work. In verbose mode, it happens when it is reading
table inheritance information.
It's a pretty simple database, only a few tables. It will be a little
bit of a pain to recreate, but not devastating. However, this install
is on my laptop, where I do a lot of my development work. I'd like to
make sure I have a reliable way of getting my databases from there to
the server.
Thanks.
Oh - Linux-Mandrake 7.0, Postgres 7.0
Michelle
-------------------------------------------
Michelle Murrain, Ph.D.
President, Norwottuck Technology Resources
mpm@norwottuck.com www.norwottuck.com
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pg_dump problems
@ 2000-09-29 05:06 Tom Lane <tgl@sss.pgh.pa.us>
parent: Michelle Murrain <mpm@norwottuck.com>
0 siblings, 0 replies; 20+ messages in thread
From: Tom Lane @ 2000-09-29 05:06 UTC (permalink / raw)
To: Michelle Murrain <mpm@norwottuck.com>; +Cc: pgsql-general
Michelle Murrain <mpm@norwottuck.com> writes:
> In doing a pg_dump on a relatively new Postgres install, I get an
> error I've never seen before:
> getInherits():SELECT failed. Explanation from backend:
> 'ERROR:Attribute 'inhre1' not found.'
IIRC, that's what you get when you run a 6.5 pg_dump against a 7.0
server. Check your PATH...
(Yes, there's a version check in pg_dump now, but there wasn't
then :-()
regards, tom lane
^ permalink raw reply [nested|flat] 20+ messages in thread
* pg_dump problems
@ 2005-12-09 11:21 durumdara@mailpont.hu <durumdara@mailpont.hu>
0 siblings, 1 reply; 20+ messages in thread
From: durumdara@mailpont.hu @ 2005-12-09 11:21 UTC (permalink / raw)
To: pgsql-general
Hi !
We have an old web service with a pgsql database (in Suse Linux). This
database created by another programmer who no accessible now.
We want to dump this database to get data from it. But I have no passwords.
I do many things, but I cannot create dump from this database.
I know the name of database (inventory), and from zope I see this
connection parameters: "dbname=inventory users=zope". And from zope that
is working good.
When I try to make pg_dump:
pg_dump -s -v -U zope -W inventory >/invdump
it prompt for pwd, and I get auth. error.
When I try to create dump with def. user:
pg_dump -s -v -W inventory >/invdump
It is show error that "root user doesn't exists".
So: how to I dump this database ? Or how to I transfer it to a Windows
machine to make dump on it ?
Is anybody have a solution ?
Thanks for advance: dd
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pg_dump problems
@ 2005-12-09 14:40 A. Kretschmer <andreas.kretschmer@schollglas.com>
parent: durumdara@mailpont.hu <durumdara@mailpont.hu>
0 siblings, 0 replies; 20+ messages in thread
From: A. Kretschmer @ 2005-12-09 14:40 UTC (permalink / raw)
To: pgsql-general
am 09.12.2005, um 12:21:25 +0100 mailte durumdara@mailpont.hu folgendes:
> Hi !
>
> We have an old web service with a pgsql database (in Suse Linux). This
> database created by another programmer who no accessible now.
>
> We want to dump this database to get data from it. But I have no passwords.
Change the trust-level in pg_hba.conf to:
local all all trust
Reload the config. Now you can login (local) without password.
For more Info:
http://www.postgresql.org/docs/8.1/interactive/client-authentication.html
HTH, Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47212, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=== Schollglas Unternehmensgruppe ===
^ permalink raw reply [nested|flat] 20+ messages in thread
* pg_dump problems
@ 2007-01-03 10:55 JTyrrell <jtyrrell_@hotmail.com>
0 siblings, 1 reply; 20+ messages in thread
From: JTyrrell @ 2007-01-03 10:55 UTC (permalink / raw)
To: pgsql-general
Hi everyone,
I'm having problems using pg_dump.
When I run the command
pg_dump -a -d testrig > testrig.data
on a machine running postgresql 7.4.13 with database testirg i have no
problem.
Then, I want to do the same but on a different machine running postgresql
7.4.6 with database root. So...
pg_dump -a -d root > root.data
For some reason this doesnt work! The command is running without error, but
the file root.data is always empty. The database does exist and all the data
is there, and I can run psql and do everything I normally do. I've tried
pg_dump with other databases and still get an empty file.
Could it be the commands are different for the different versions? If thats
the case, does anyone know what command I should be running?
--
View this message in context: http://www.nabble.com/pg_dump-problems-tf2912789.html#a8138723
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pg_dump problems
@ 2007-01-03 19:01 Richard Huxton <dev@archonet.com>
parent: JTyrrell <jtyrrell_@hotmail.com>
0 siblings, 1 reply; 20+ messages in thread
From: Richard Huxton @ 2007-01-03 19:01 UTC (permalink / raw)
To: JTyrrell <jtyrrell_@hotmail.com>; +Cc: pgsql-general
JTyrrell wrote:
>
> pg_dump -a -d testrig > testrig.data
>
> on a machine running postgresql 7.4.13 with database testirg i have no
> problem.
>
> Then, I want to do the same but on a different machine running postgresql
> 7.4.6 with database root. So...
>
> pg_dump -a -d root > root.data
>
> For some reason this doesnt work! The command is running without error, but
> the file root.data is always empty. The database does exist and all the data
> is there, and I can run psql and do everything I normally do. I've tried
> pg_dump with other databases and still get an empty file.
Should work just fine.
1. Does "pg_dump -s" work?
2. Does the user you run this as have permission to dump data from "root"?
--
Richard Huxton
Archonet Ltd
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pg_dump problems
@ 2007-01-04 09:20 JTyrrell <jtyrrell_@hotmail.com>
parent: Richard Huxton <dev@archonet.com>
0 siblings, 1 reply; 20+ messages in thread
From: JTyrrell @ 2007-01-04 09:20 UTC (permalink / raw)
To: pgsql-general
Richard Huxton wrote:
>
> JTyrrell wrote:
>>
>> pg_dump -a -d testrig > testrig.data
>>
>> on a machine running postgresql 7.4.13 with database testirg i have no
>> problem.
>>
>> Then, I want to do the same but on a different machine running postgresql
>> 7.4.6 with database root. So...
>>
>> pg_dump -a -d root > root.data
>>
>> For some reason this doesnt work! The command is running without error,
>> but
>> the file root.data is always empty. The database does exist and all the
>> data
>> is there, and I can run psql and do everything I normally do. I've tried
>> pg_dump with other databases and still get an empty file.
>
> Should work just fine.
> 1. Does "pg_dump -s" work?
> 2. Does the user you run this as have permission to dump data from "root"?
>
> --
> Richard Huxton
> Archonet Ltd
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
>
1. pg_dump -s doesn't work. I've tried using a load of other options and
none at all but no luck.
2. I'm running as root so wont be a problem there, and the file im dumping
to has full permissions for everyone.
What makes this even more confusing is I tried pg_dump with a database name
that doesnt exist and tried dumping from database root with a user that
doesn't have permission to do that. Both gave the same results as before.
Its basically creating the file i need, looking for the database and not
finding it. When you dump an empty database the file at least has some info
on session authorization and the schema. Im getting nothing!
--
View this message in context: http://www.nabble.com/pg_dump-problems-tf2912789.html#a8156139
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pg_dump problems
@ 2007-01-04 18:39 Tom Lane <tgl@sss.pgh.pa.us>
parent: JTyrrell <jtyrrell_@hotmail.com>
0 siblings, 1 reply; 20+ messages in thread
From: Tom Lane @ 2007-01-04 18:39 UTC (permalink / raw)
To: JTyrrell <jtyrrell_@hotmail.com>; +Cc: pgsql-general
JTyrrell <jtyrrell_@hotmail.com> writes:
> 1. pg_dump -s doesn't work. I've tried using a load of other options and
> none at all but no luck.
> 2. I'm running as root so wont be a problem there, and the file im dumping
> to has full permissions for everyone.
> What makes this even more confusing is I tried pg_dump with a database name
> that doesnt exist and tried dumping from database root with a user that
> doesn't have permission to do that. Both gave the same results as before.
> Its basically creating the file i need, looking for the database and not
> finding it. When you dump an empty database the file at least has some info
> on session authorization and the schema. Im getting nothing!
It's really hard to believe that pg_dump would write nothing to either
the output file or stderr. The only thought that comes to mind is that
if this machine has SELinux enabled, the SELinux policy might be
forbidding it from writing on the output file. What's the platform,
exactly?
regards, tom lane
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pg_dump problems
@ 2007-01-05 09:16 JTyrrell <jtyrrell_@hotmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 20+ messages in thread
From: JTyrrell @ 2007-01-05 09:16 UTC (permalink / raw)
To: pgsql-general
Im using Red Hat Enterprise Linux 4. Thing is it worked before christmas but
doesn't now. I've just moved the data across by hand so its not too much of
a problem anymore. Might need to use dump again though so would be nice to
get the problem fixed
Tom Lane-2 wrote:
>
> JTyrrell <jtyrrell_@hotmail.com> writes:
>> 1. pg_dump -s doesn't work. I've tried using a load of other options and
>> none at all but no luck.
>
>> 2. I'm running as root so wont be a problem there, and the file im
>> dumping
>> to has full permissions for everyone.
>
>> What makes this even more confusing is I tried pg_dump with a database
>> name
>> that doesnt exist and tried dumping from database root with a user that
>> doesn't have permission to do that. Both gave the same results as before.
>> Its basically creating the file i need, looking for the database and not
>> finding it. When you dump an empty database the file at least has some
>> info
>> on session authorization and the schema. Im getting nothing!
>
> It's really hard to believe that pg_dump would write nothing to either
> the output file or stderr. The only thought that comes to mind is that
> if this machine has SELinux enabled, the SELinux policy might be
> forbidding it from writing on the output file. What's the platform,
> exactly?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org/
>
>
--
View this message in context: http://www.nabble.com/pg_dump-problems-tf2912789.html#a8175027
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
^ permalink raw reply [nested|flat] 20+ messages in thread
* pg_dump problems
@ 2011-03-23 12:33 Martín Marqués <martin.marques@gmail.com>
0 siblings, 1 reply; 20+ messages in thread
From: Martín Marqués @ 2011-03-23 12:33 UTC (permalink / raw)
To: pgsql-general
Hi all,
I'm having problems with pg_dump, apparently, from one of our servers.
The scenario is like this. I tried today to dump a DB from our
production server to load on our development server and got some
errors, which I show below.
Production server:
SELECT version();
version
-----------------------------------------------------------------------------------------------
PostgreSQL 8.3.14 on i486-pc-linux-gnu, compiled by GCC gcc-4.3.real
(Debian 4.3.2-1.1) 4.3.2
Development server:
SELECT version();
version
-----------------------------------------------------------------------------------------------------
PostgreSQL 8.4.7 on i486-pc-linux-gnu, compiled by GCC gcc-4.4.real
(Debian 4.4.5-10) 4.4.5, 32-bit
Anyway, the problem is in the output of the pg_dump in the production server:
$ pg_dump -V
pg_dump (PostgreSQL) 8.3.14
The first error looks like related to encoding of bytea:
ERROR: sintaxis de entrada no válida para tipo bytea
CONTEXTO: COPY novedades_fotos, línea 23, columna foto:
«\377\330\377\340\000\020JFIF\000\001\002\001\000H\000H\000\000\377\355\020\006Photoshop
3.0\0008BIM\...»
But more strange is what comes later:
ERROR: la sintaxis de entrada no es válida para integer: «954516ILa
educación superior en el sector aducativo del mercosur»
CONTEXTO: COPY objeto_datos_rep, línea 1627732, columna codiobjeto:
«954516ILa educación superior en el sector aducativo del mercosur»
Checking that register in the production DB I get this:
SELECT * from objeto_datos_rep where codigo = 2357634;
codigo | codiobjeto | descripcion
| tcampo
---------+------------+-----------------------------------------------------------+--------
2357634 | 954516 | La educación superior en el sector aducativo
del mercosur | 5
So, why didn't pg_dump add the tabs between 954516 and "La educación..."?
Right now I'm trying to do dump with INSERTs instead of COPY command
to see what happens.
--
Martín Marqués
select 'martin.marques' || '@' || 'gmail.com'
DBA, Programador, Administrador
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pg_dump problems
@ 2011-03-23 12:40 Vick Khera <vivek@khera.org>
parent: Martín Marqués <martin.marques@gmail.com>
0 siblings, 1 reply; 20+ messages in thread
From: Vick Khera @ 2011-03-23 12:40 UTC (permalink / raw)
To: pgsql-general
2011/3/23 Martín Marqués <martin.marques@gmail.com>:
> The scenario is like this. I tried today to dump a DB from our
> production server to load on our development server and got some
> errors, which I show below.
Try using the pg_dump from the 8.4 install to create your dump file.
Also make sure your 8.3 installation doesn't have a non-default bytea
encoding setting (not sure when that setting was introduced, so there
may not even be such a setting).
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pg_dump problems
@ 2011-03-23 13:57 Martín Marqués <martin.marques@gmail.com>
parent: Vick Khera <vivek@khera.org>
0 siblings, 1 reply; 20+ messages in thread
From: Martín Marqués @ 2011-03-23 13:57 UTC (permalink / raw)
To: Vick Khera <vivek@khera.org>; +Cc: pgsql-general
Now I'm getting weirder things. I did a pg_dump with -d option and the
dump adds strange caracters:
ERROR: error de sintaxis en o cerca de «I»
LÍNEA 1: I^NSERT INTO objeto_datos_rep VALUES (1172339, 387943, 'Wilde...
Could it be binary corruption (pg_dump for example)?
2011/3/23 Vick Khera <vivek@khera.org>:
> 2011/3/23 Martín Marqués <martin.marques@gmail.com>:
>> The scenario is like this. I tried today to dump a DB from our
>> production server to load on our development server and got some
>> errors, which I show below.
>
>
> Try using the pg_dump from the 8.4 install to create your dump file.
I'll try this.
> Also make sure your 8.3 installation doesn't have a non-default bytea
> encoding setting (not sure when that setting was introduced, so there
> may not even be such a setting).
bytea has encoding? I thought it was plain binary data.
--
Martín Marqués
select 'martin.marques' || '@' || 'gmail.com'
DBA, Programador, Administrador
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pg_dump problems
@ 2011-03-23 14:18 Adrian Klaver <adrian.klaver@gmail.com>
parent: Martín Marqués <martin.marques@gmail.com>
0 siblings, 1 reply; 20+ messages in thread
From: Adrian Klaver @ 2011-03-23 14:18 UTC (permalink / raw)
To: pgsql-general; +Cc: Martín Marqués <martin.marques@gmail.com>; Vick Khera <vivek@khera.org>
On Wednesday, March 23, 2011 6:57:35 am Martín Marqués wrote:
> Now I'm getting weirder things. I did a pg_dump with -d option and the
> dump adds strange caracters:
As previously stated try using the 8.4 version of pg_dump to dump the 8.3
database. FYI in 8.4+ there is no -d option anymore, it has become --inserts to
reduce confusion with other commands where -d specified the database.
>
> ERROR: error de sintaxis en o cerca de «I»
> LÍNEA 1: I^NSERT INTO objeto_datos_rep VALUES (1172339, 387943, 'Wilde...
>
> Could it be binary corruption (pg_dump for example)?
>
> 2011/3/23 Vick Khera <vivek@khera.org>:
> > 2011/3/23 Martín Marqués <martin.marques@gmail.com>:
> >> The scenario is like this. I tried today to dump a DB from our
> >> production server to load on our development server and got some
> >> errors, which I show below.
> >
> > Try using the pg_dump from the 8.4 install to create your dump file.
>
> I'll try this.
>
> > Also make sure your 8.3 installation doesn't have a non-default bytea
> > encoding setting (not sure when that setting was introduced, so there
> > may not even be such a setting).
>
> bytea has encoding? I thought it was plain binary data.
I think he was talking about bytea_output, which appeared in 9.0.
In any event you may want to verify that the encodings/locales for the two
databases are the same.
--
Adrian Klaver
adrian.klaver@gmail.com
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pg_dump problems
@ 2011-03-23 14:56 Martín Marqués <martin.marques@gmail.com>
parent: Adrian Klaver <adrian.klaver@gmail.com>
0 siblings, 1 reply; 20+ messages in thread
From: Martín Marqués @ 2011-03-23 14:56 UTC (permalink / raw)
To: adrian.klaver@gmail.com; +Cc: pgsql-general@postgresql.org, Vick Khera <vivek@khera.org>
El día 23 de marzo de 2011 11:18, Adrian Klaver
<adrian.klaver@gmail.com> escribió:
> On Wednesday, March 23, 2011 6:57:35 am Martín Marqués wrote:
>
>> Now I'm getting weirder things. I did a pg_dump with -d option and the
>
>> dump adds strange caracters:
>
> As previously stated try using the 8.4 version of pg_dump to dump the 8.3
> database. FYI in 8.4+ there is no -d option anymore, it has become --inserts
> to reduce confusion with other commands where -d specified the database.
Ok, did a remote dump (from the development server which has pg 8.4)
and I got a similar error:
psql:siprebi-bu.sql:27374: ERROR: sintaxis de entrada no
v<C3><A1>lida para tipo bytea
CONTEXT: COPY novedades_fotos, l<C3><AD>nea 273, columna foto:
<C2><AB>\377\330\377\340\000\020JFIF\000\001\001\001\000`\000`\000\000\377\341<\310Exif\000\000II
*\000\010\0...<C2><BB>
psql:siprebi-bu.sql:3477848: ERROR: la sintaxis de entrada no es
v<C3><A1>lida para integer: <C2><AB>q43116<C2><BB>
CONTEXT: COPY objetos, l<C3><AD>nea 99185, columna codigo:
<C2><AB>q43116<C2><BB>
>
>> > Also make sure your 8.3 installation doesn't have a non-default bytea
>
>> > encoding setting (not sure when that setting was introduced, so there
>
>> > may not even be such a setting).
>
>>
>
>> bytea has encoding? I thought it was plain binary data.
>
> I think he was talking about bytea_output, which appeared in 9.0.
>
> In any event you may want to verify that the encodings/locales for the two
> databases are the same.
>
All configurations have UTF-8
--
Martín Marqués
select 'martin.marques' || '@' || 'gmail.com'
DBA, Programador, Administrador
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pg_dump problems
@ 2011-03-23 17:03 Adrian Klaver <adrian.klaver@gmail.com>
parent: Martín Marqués <martin.marques@gmail.com>
0 siblings, 1 reply; 20+ messages in thread
From: Adrian Klaver @ 2011-03-23 17:03 UTC (permalink / raw)
To: Martín Marqués <martin.marques@gmail.com>; +Cc: pgsql-general@postgresql.org, Vick Khera <vivek@khera.org>
On 03/23/2011 07:56 AM, Martín Marqués wrote:
> El día 23 de marzo de 2011 11:18, Adrian Klaver
> <adrian.klaver@gmail.com> escribió:
>> On Wednesday, March 23, 2011 6:57:35 am Martín Marqués wrote:
>>
>>> Now I'm getting weirder things. I did a pg_dump with -d option and the
>>
>>> dump adds strange caracters:
>>
>> As previously stated try using the 8.4 version of pg_dump to dump the 8.3
>> database. FYI in 8.4+ there is no -d option anymore, it has become --inserts
>> to reduce confusion with other commands where -d specified the database.
>
>
> Ok, did a remote dump (from the development server which has pg 8.4)
> and I got a similar error:
>
> psql:siprebi-bu.sql:27374: ERROR: sintaxis de entrada no
> v<C3><A1>lida para tipo bytea
> CONTEXT: COPY novedades_fotos, l<C3><AD>nea 273, columna foto:
> <C2><AB>\377\330\377\340\000\020JFIF\000\001\001\001\000`\000`\000\000\377\341<\310Exif\000\000II
> *\000\010\0...<C2><BB>
> psql:siprebi-bu.sql:3477848: ERROR: la sintaxis de entrada no es
> v<C3><A1>lida para integer:<C2><AB>q43116<C2><BB>
> CONTEXT: COPY objetos, l<C3><AD>nea 99185, columna codigo:
> <C2><AB>q43116<C2><BB>
>
So you are feeding a plain text dump to psql correct?
Does the data in the file look correct for the affected tables?
Are there any other errors being reported?
--
Adrian Klaver
adrian.klaver@gmail.com
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pg_dump problems
@ 2011-03-23 17:33 Martín Marqués <martin.marques@gmail.com>
parent: Adrian Klaver <adrian.klaver@gmail.com>
0 siblings, 2 replies; 20+ messages in thread
From: Martín Marqués @ 2011-03-23 17:33 UTC (permalink / raw)
To: Adrian Klaver <adrian.klaver@gmail.com>; +Cc: pgsql-general@postgresql.org, Vick Khera <vivek@khera.org>
El día 23 de marzo de 2011 14:03, Adrian Klaver
<adrian.klaver@gmail.com> escribió:
> On 03/23/2011 07:56 AM, Martín Marqués wrote:
>>
>>
>> Ok, did a remote dump (from the development server which has pg 8.4)
>> and I got a similar error:
>>
>> psql:siprebi-bu.sql:27374: ERROR: sintaxis de entrada no
>> v<C3><A1>lida para tipo bytea
>> CONTEXT: COPY novedades_fotos, l<C3><AD>nea 273, columna foto:
>>
>> <C2><AB>\377\330\377\340\000\020JFIF\000\001\001\001\000`\000`\000\000\377\341<\310Exif\000\000II
>> *\000\010\0...<C2><BB>
>> psql:siprebi-bu.sql:3477848: ERROR: la sintaxis de entrada no es
>> v<C3><A1>lida para integer:<C2><AB>q43116<C2><BB>
>> CONTEXT: COPY objetos, l<C3><AD>nea 99185, columna codigo:
>> <C2><AB>q43116<C2><BB>
>>
>
> So you are feeding a plain text dump to psql correct?
How can I verify this? It's already dificult to manage the file, asi
it has over 700Mb.
The second error is very curious, as it looks like pg_dump changed 1
for a 'q' in an integer field:
psql:siprebi-bu.sql:2219245: ERROR: la sintaxis de entrada no es
válida para integer: «q721695»
CONTEXT: COPY objeto_datos_rep, línea 991894, columna codigo: «q721695»
Looking at the dump file I see this:
1721693 657083 Eclairage... 5
1721694 657083 photometrie 5
q721695 657084 Keitz, H. A. E. 2
1721696 657084 Ligth calculations and measurements... 5
1721697 657085 La Toison, M. 2
> Does the data in the file look correct for the affected tables?
> Are there any other errors being reported?
Thats the first error. After that there are similar errores and others
related to that register not gentting inserted (foreign keys that
don't have there corresponding primary key).
--
Martín Marqués
select 'martin.marques' || '@' || 'gmail.com'
DBA, Programador, Administrador
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pg_dump problems
@ 2011-03-23 17:37 Vick Khera <vivek@khera.org>
parent: Martín Marqués <martin.marques@gmail.com>
1 sibling, 1 reply; 20+ messages in thread
From: Vick Khera @ 2011-03-23 17:37 UTC (permalink / raw)
To: pgsql-general
2011/3/23 Martín Marqués <martin.marques@gmail.com>:
> The second error is very curious, as it looks like pg_dump changed 1
> for a 'q' in an integer field:
>
> psql:siprebi-bu.sql:2219245: ERROR: la sintaxis de entrada no es
> válida para integer: «q721695»
> CONTEXT: COPY objeto_datos_rep, línea 991894, columna codigo: «q721695»
>
That's a single-bit error. I'm voting hardware problems. Does your
memory have ECC? How reliable is your disk?
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pg_dump problems
@ 2011-03-23 17:38 Adrian Klaver <adrian.klaver@gmail.com>
parent: Martín Marqués <martin.marques@gmail.com>
1 sibling, 0 replies; 20+ messages in thread
From: Adrian Klaver @ 2011-03-23 17:38 UTC (permalink / raw)
To: Martín Marqués <martin.marques@gmail.com>; +Cc: pgsql-general@postgresql.org, Vick Khera <vivek@khera.org>
On 03/23/2011 10:33 AM, Martín Marqués wrote:
> El día 23 de marzo de 2011 14:03, Adrian Klaver
> <adrian.klaver@gmail.com> escribió:
>> On 03/23/2011 07:56 AM, Martín Marqués wrote:
>>>
>>>
>>> Ok, did a remote dump (from the development server which has pg 8.4)
>>> and I got a similar error:
>>>
>>> psql:siprebi-bu.sql:27374: ERROR: sintaxis de entrada no
>>> v<C3><A1>lida para tipo bytea
>>> CONTEXT: COPY novedades_fotos, l<C3><AD>nea 273, columna foto:
>>>
>>> <C2><AB>\377\330\377\340\000\020JFIF\000\001\001\001\000`\000`\000\000\377\341<\310Exif\000\000II
>>> *\000\010\0...<C2><BB>
>>> psql:siprebi-bu.sql:3477848: ERROR: la sintaxis de entrada no es
>>> v<C3><A1>lida para integer:<C2><AB>q43116<C2><BB>
>>> CONTEXT: COPY objetos, l<C3><AD>nea 99185, columna codigo:
>>> <C2><AB>q43116<C2><BB>
>>>
>>
>> So you are feeding a plain text dump to psql correct?
>
> How can I verify this? It's already dificult to manage the file, asi
> it has over 700Mb.
One way would be to dump only the table(s) that are causing the problem.
>
> The second error is very curious, as it looks like pg_dump changed 1
> for a 'q' in an integer field:
My guess is that it is combining data from two fields. In other words
the 'q' is the end of the previous field.
>
> psql:siprebi-bu.sql:2219245: ERROR: la sintaxis de entrada no es
> válida para integer: «q721695»
> CONTEXT: COPY objeto_datos_rep, línea 991894, columna codigo: «q721695»
>
> Looking at the dump file I see this:
>
> 1721693 657083 Eclairage... 5
> 1721694 657083 photometrie 5
> q721695 657084 Keitz, H. A. E. 2
> 1721696 657084 Ligth calculations and measurements... 5
> 1721697 657085 La Toison, M. 2
>
>> Does the data in the file look correct for the affected tables?
>> Are there any other errors being reported?
>
> Thats the first error. After that there are similar errores and others
> related to that register not gentting inserted (foreign keys that
> don't have there corresponding primary key).
>
--
Adrian Klaver
adrian.klaver@gmail.com
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pg_dump problems
@ 2011-03-23 19:28 Martín Marqués <martin.marques@gmail.com>
parent: Vick Khera <vivek@khera.org>
0 siblings, 1 reply; 20+ messages in thread
From: Martín Marqués @ 2011-03-23 19:28 UTC (permalink / raw)
To: Vick Khera <vivek@khera.org>; +Cc: pgsql-general
2011/3/23 Vick Khera <vivek@khera.org>:
> 2011/3/23 Martín Marqués <martin.marques@gmail.com>:
>> The second error is very curious, as it looks like pg_dump changed 1
>> for a 'q' in an integer field:
>>
>> psql:siprebi-bu.sql:2219245: ERROR: la sintaxis de entrada no es
>> válida para integer: «q721695»
>> CONTEXT: COPY objeto_datos_rep, línea 991894, columna codigo: «q721695»
>>
>
> That's a single-bit error. I'm voting hardware problems. Does your
> memory have ECC? How reliable is your disk?
>
The production server is a Compaq Prolaint, with ECC memory and RAID
by hardware.
How can I discard, or affirm that we are dealing with hardware problems?
--
Martín Marqués
select 'martin.marques' || '@' || 'gmail.com'
DBA, Programador, Administrador
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pg_dump problems
@ 2011-03-30 14:40 Martín Marqués <martin.marques@gmail.com>
parent: Martín Marqués <martin.marques@gmail.com>
0 siblings, 0 replies; 20+ messages in thread
From: Martín Marqués @ 2011-03-30 14:40 UTC (permalink / raw)
To: Vick Khera <vivek@khera.org>; +Cc: pgsql-general
Just to to finish this thread:
We had a corrupted memory bank in the development server, and that
was, for some reason corrupting the data that got written to disk.
All is good now. Sorry for the noise.
El día 23 de marzo de 2011 16:28, Martín Marqués
<martin.marques@gmail.com> escribió:
> 2011/3/23 Vick Khera <vivek@khera.org>:
>> 2011/3/23 Martín Marqués <martin.marques@gmail.com>:
>>> The second error is very curious, as it looks like pg_dump changed 1
>>> for a 'q' in an integer field:
>>>
>>> psql:siprebi-bu.sql:2219245: ERROR: la sintaxis de entrada no es
>>> válida para integer: «q721695»
>>> CONTEXT: COPY objeto_datos_rep, línea 991894, columna codigo: «q721695»
>>>
>>
>> That's a single-bit error. I'm voting hardware problems. Does your
>> memory have ECC? How reliable is your disk?
>>
>
> The production server is a Compaq Prolaint, with ECC memory and RAID
> by hardware.
>
> How can I discard, or affirm that we are dealing with hardware problems?
>
> --
> Martín Marqués
> select 'martin.marques' || '@' || 'gmail.com'
> DBA, Programador, Administrador
>
--
Martín Marqués
select 'martin.marques' || '@' || 'gmail.com'
DBA, Programador, Administrador
^ permalink raw reply [nested|flat] 20+ messages in thread
end of thread, other threads:[~2011-03-30 14:40 UTC | newest]
Thread overview: 20+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2000-09-27 20:25 pg_dump problems Michelle Murrain <mpm@norwottuck.com>
2000-09-29 05:06 ` Tom Lane <tgl@sss.pgh.pa.us>
2005-12-09 11:21 pg_dump problems durumdara@mailpont.hu <durumdara@mailpont.hu>
2005-12-09 14:40 ` A. Kretschmer <andreas.kretschmer@schollglas.com>
2007-01-03 10:55 pg_dump problems JTyrrell <jtyrrell_@hotmail.com>
2007-01-03 19:01 ` Richard Huxton <dev@archonet.com>
2007-01-04 09:20 ` JTyrrell <jtyrrell_@hotmail.com>
2007-01-04 18:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2007-01-05 09:16 ` JTyrrell <jtyrrell_@hotmail.com>
2011-03-23 12:33 pg_dump problems Martín Marqués <martin.marques@gmail.com>
2011-03-23 12:40 ` Vick Khera <vivek@khera.org>
2011-03-23 13:57 ` Martín Marqués <martin.marques@gmail.com>
2011-03-23 14:18 ` Adrian Klaver <adrian.klaver@gmail.com>
2011-03-23 14:56 ` Martín Marqués <martin.marques@gmail.com>
2011-03-23 17:03 ` Adrian Klaver <adrian.klaver@gmail.com>
2011-03-23 17:33 ` Martín Marqués <martin.marques@gmail.com>
2011-03-23 17:37 ` Vick Khera <vivek@khera.org>
2011-03-23 19:28 ` Martín Marqués <martin.marques@gmail.com>
2011-03-30 14:40 ` Martín Marqués <martin.marques@gmail.com>
2011-03-23 17:38 ` Adrian Klaver <adrian.klaver@gmail.com>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox