From: | Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: 7.1.2: Backend message type 0x44 when selecting |
Date: | 2001-11-19 04:50:24 |
Message-ID: | 3.0.5.32.20011119125024.00a7d600@192.228.128.13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
At 11:18 PM 18-11-2001 -0500, Tom Lane wrote:
>Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> writes:
>> Trying to pg_dump the table gives me this:
>> <snipped>
>> ERROR: MemoryContextAlloc: invalid request size 1163153238
>> PQendcopy: resetting connection
>
>This looks like a corrupted-data problem ...
Yah. Timestamp was BC :).
>> I've truncated the table and it runs ok now.
>
>... but the evidence is now gone, so we can't really probe into it
>further :-(. You might be well advised to run some hardware diagnostics
>to see if you have any RAM problems, flaky disk controllers, that sort
>of thing. Not that Postgres has no bugs, of course, but we've seen
>quite a number of data-corruption reports that ultimately traced to
>hardware problems.
>The behavior during a SELECT seems odd also:
>
>> SELECT * from arch_ranks_arch4 ;
>> Backend message type 0x44 arrived while idle
>> pqReadData() -- backend closed the channel unexpectedly.
>
>This suggests that libpq and the backend got out of sync somehow,
>but I thought we'd fixed that class of problems years ago. If you
>can reproduce this it'd be worth looking into.
I'll try to upgrade to 7.1.3. Then if it happens again it'll mean more.
Cheerio,
Link.
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua Adam Ginsberg | 2001-11-19 06:56:15 | Packages for RH7.2 |
Previous Message | Tom Lane | 2001-11-19 04:18:35 | Re: 7.1.2: Backend message type 0x44 when selecting from a table |