From: | Stefan Holzheu <stefan(dot)holzheu(at)bitoek(dot)uni-bayreuth(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | ADMIN <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: Problems with pg_dump |
Date: | 2004-01-26 19:29:33 |
Message-ID: | 40156A9D.5040302@bitoek.uni-bayreuth.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
>
>>pg_dump: lost synchronization with server: got message type "5", length
>>842281016
>
>
>>The error does not occur always and not always with the same table.
>
>
> Oh, that's even more interesting. Is the failure message itself
> consistent --- that is, is it always complaining about "message type 5"
> and the same bizarre length value? The "length" looks like it's really
> ASCII text ("2408" to be specific), so somehow libpq is misinterpreting
> a piece of the COPY datastream as the start of a new message.
>
The failure looks similarly but the number do not exactly the same:
pg_dump: lost synchronization with server: got message type "4", length
858863113
pg_dump: SQL command to dump the contents of table "aggr_max_hour"
failed: PQendcopy() failed.
pg_dump: Error message from server: lost synchronization with server:
got message type "4", length 858863113
pg_dump: The command was: COPY messungen.aggr_max_hour (id, von, wert,
counts) TO stdout;
>
>>However, the error occurs only on that kind of aggregation tables. There
>>is a cron-job keeping the tables up to date, starting all 10 minutes.
>>The job does delete and inserts on the table. Could this somehow block
>>the dump process? Normally it should not?
>
>
> It's hard to see how another backend would have anything to do with
> this, unless perhaps the error is dependent on a particular data value
> that is sometimes present in the table and sometimes not. It looks to
> me like either libpq or the backend is miscounting the number of data
> bytes in the COPY datastream. Would it be possible for you to use a
> packet sniffer to capture the communication between pg_dump and the
> backend? If we could look at exactly what's going over the wire, it
> would help to pin down the blame.
>
Well, I never used a packet sniffer but if anyone tells me what to
capture, I'd be glad to.
PostgreSQL is really a great piece of software, keep on making it even
better!
Stefan
--
-----------------------------
Dr. Stefan Holzheu
Tel.: 0921/55-5720
Fax.: 0921/55-5799
BITOeK Wiss. Sekretariat
Universitaet Bayreuth
D-95440 Bayreuth
-----------------------------
From | Date | Subject | |
---|---|---|---|
Next Message | Yuji Shinozaki | 2004-01-26 19:36:15 | Re: [Fwd: binary tree query] |
Previous Message | Jodi Kanter | 2004-01-26 19:16:13 | [Fwd: binary tree query] |