Exit code -1073741819
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
2013-07-30 21:35:47 LOG: terminating any other active server processes
2013-07-30 21:35:47 WARNING: terminating connection because of crash of
another server process
Is this related with a hardware problem or some operational system issue?
Do a Windows reinstall or an windows upgrade fix the issue?
Thank you in advance!
--
Reimer
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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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?
Thank you!
On Sun, Aug 4, 2013 at 8:35 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
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 -1073741819This 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
--
Reimer
47-3347-1724 47-9183-0547 msn: carlos.reimer@opendb.com.br
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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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.
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 <carlos.reimer@opendb.com.br>>--
Adrian Klaver
adrian.klaver@gmail.com
--
Reimer
47-3347-1724 47-9183-0547 msn: carlos.reimer@opendb.com.br
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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hi,
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.
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?
Thank you!
On Tue, Aug 6, 2013 at 9:14 PM, Sergey Konoplev <gray.ru@gmail.com> wrote:
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 DBAProfile: 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
--
Reimer
47-3347-1724 47-9183-0547 msn: carlos.reimer@opendb.com.br
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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general