Skip site navigation (1) Skip section navigation (2)

Re: Problems with pg_dump

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stefan Holzheu <stefan(dot)holzheu(at)bitoek(dot)uni-bayreuth(dot)de>
Cc: ADMIN <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Problems with pg_dump
Date: 2004-01-26 16:19:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Stefan Holzheu <stefan(dot)holzheu(at)bitoek(dot)uni-bayreuth(dot)de> writes:
> 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.

> 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.

			regards, tom lane

In response to


pgsql-admin by date

Next:From: Raquel VieiraDate: 2004-01-26 16:34:46
Subject: Re: A question?
Previous:From: Greg StarkDate: 2004-01-26 16:16:28
Subject: Re: High Performance/High Reliability File system on SuSE64

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group