Обсуждение: Exit code -1073741819

On 08/04/2013 02:41 AM, Carlos Henrique Reimer wrote:
> Hi,
>
> I have a Windows box running Windows Server 2003 Enterprise Edition
> Service Pack 2 with PostgreSQL 8.2.23 and getting a server crash while
> trying to select a table:
>
> select * from "TOTALL.tt_est" where assina=' kdkd' ;
>
> Dumping the table with pg_dump or creating indexes in this table produce
> the same error.
>
> 2013-07-30 21:35:47 LOG:  server process (PID 2004) exited with exit
> code -1073741819

This looks like an invalid memory access error. This could be caused by
practically anything - hardware issues, malware hook DLLs, drivers,
antivirus, you name it.

You're using PostgreSQL 8.2, so honestly your first step is probably
"just upgrade". 8.2 is old and unsupported
(www.postgresql.org/support/versioning/), so there's very little point
investigating a bug until it can be reproduced in a current version.

Can you `pg_dump` your database? If so, follow the upgrade instructions
in the documentation to get onto a current, supported version.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On 08/05/2013 06:24 AM, Carlos Henrique Reimer wrote:
> Hi,
>
> Yes, I agree with you that it must be upgraded to a supported version
> but as the developer has not homologated the system to some new PG
> versions yet I need to find out some way to fix it with 8.2.
>
> Will try to install PG in another windows box, copying the data
> directories over the network and see if I can at least take a pg_dump
> from the database as it is currently not possible.
>
> Another possibility is to copy the data directory from the windows box
> to a linux with PG 8.2 and start the database there, does this approach
> has any possibility of success?

No. The files are not binary compatible across OS and architectures.

You mentioned that creating indexes on this table fails.

Have you tried reindexing or dropping the index to see if that helps?


>
>
> Thank you!
>
>
>
> Reimer
> 47-3347-1724 47-9183-0547 msn: carlos.reimer@opendb.com.br
> <mailto:carlos.reimer@opendb.com.br>


--
Adrian Klaver
adrian.klaver@gmail.com

On 08/06/2013 04:17 PM, Carlos Henrique Reimer wrote:
> Hi,
>
> Thank you for the feedback!
>
> I have tried to drop the index and the reindex procedure but both fail
> with the same exit code.
>
> Copied the data directory to another partition on same HD but same results.
>
> Next change window will install PG 8.2.23 in another Windows box and
> copy the data directory to the new box.
>
> Hope the error will not be propagated to the new box.

Hope springs eternal, but given the lack of success copying to a new
partition I would think moving to a new box will not help either.

Can you do anything with the table, for instance a simple select *  ?

>
>
> Reimer
>


--
Adrian Klaver
adrian.klaver@gmail.com

On Tue, Aug 6, 2013 at 4:17 PM, Carlos Henrique Reimer
<carlos.reimer@opendb.com.br> wrote:
> I have tried to drop the index and the reindex procedure but both fail with
> the same exit code.
>
> Copied the data directory to another partition on same HD but same results.
>
> Next change window will install PG 8.2.23 in another Windows box and copy
> the data directory to the new box.
>
> Hope the error will not be propagated to the new box.

If it wont help try to find out which rows lead to the failure, and
copy your data from this table to a new one with the same structure
filtering this rows. Then drop the old one and rename the new one. You
might also need to drop all the FKs preliminary before doing this and
restore them after.

To find out which rows are bad use manual binary search
(http://en.wikipedia.org/wiki/Binary_search_algorithm) by PK.

To copy data use CREATE TABLE newone (LIKE ...)  and then INSERT INTO
newone SELECT ... WHERE id NOT IN (...).

>
>
> Reimer
>
>
> On Mon, Aug 5, 2013 at 10:42 AM, Adrian Klaver <adrian.klaver@gmail.com>
> wrote:
>>
>> On 08/05/2013 06:24 AM, Carlos Henrique Reimer wrote:
>>>
>>> Hi,
>>>
>>> Yes, I agree with you that it must be upgraded to a supported version
>>> but as the developer has not homologated the system to some new PG
>>> versions yet I need to find out some way to fix it with 8.2.
>>>
>>> Will try to install PG in another windows box, copying the data
>>> directories over the network and see if I can at least take a pg_dump
>>> from the database as it is currently not possible.
>>>
>>> Another possibility is to copy the data directory from the windows box
>>> to a linux with PG 8.2 and start the database there, does this approach
>>> has any possibility of success?
>>
>>
>> No. The files are not binary compatible across OS and architectures.
>>
>> You mentioned that creating indexes on this table fails.
>>
>> Have you tried reindexing or dropping the index to see if that helps?
>>
>>
>>>
>>>
>>> Thank you!
>>>
>>>
>>>
>>> Reimer
>>> 47-3347-1724 47-9183-0547 msn: carlos.reimer@opendb.com.br
>>> <mailto:carlos.reimer@opendb.com.br>
>>
>>
>>
>> --
>> Adrian Klaver
>> adrian.klaver@gmail.com
>
>
>
>
> --
> Reimer
> 47-3347-1724 47-9183-0547 msn: carlos.reimer@opendb.com.br



--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA

Profile: http://www.linkedin.com/in/grayhemp
Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979
Skype: gray-hemp
Jabber: gray.ru@gmail.com

On Wed, Aug 7, 2013 at 2:46 PM, Carlos Henrique Reimer
<carlos.reimer@opendb.com.br> wrote:
> Could finally fix it. Used the binary search approach to identify the wrong
> tuples and removed them by ctid, 9 rows were removed and all of them
> belonged to the same block.

It is good. I still highly recommend to recreate the table, because
the corruption might implicitly affect page headers too.

> I believe it is not easy to identify the root cause for the corruption but
> does any one have some directions I could follow to identify the root cause
> in order to prevent it to happen again?

Check logs, both system and postgres, for suspicious activity, find
out if there were any power problems, server resets, etc.

Upgrade your cluster to the latest version first of all, install a
RAID controller with BBU, perform periodical SQL backups, and the PITR
backups to be able to restore on a particular moment of time.

--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA

Profile: http://www.linkedin.com/in/grayhemp
Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979
Skype: gray-hemp
Jabber: gray.ru@gmail.com