Re: Problems with pg_dump
От | Stefan Holzheu |
---|---|
Тема | Re: Problems with pg_dump |
Дата | |
Msg-id | 40156A9D.5040302@bitoek.uni-bayreuth.de обсуждение исходный текст |
Ответ на | Re: Problems with pg_dump (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Problems with pg_dump
Re: Problems with pg_dump |
Список | 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 -----------------------------
В списке pgsql-admin по дате отправления: