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
On Wed, Aug 7, 2013 at 2:46 PM, Carlos Henrique Reimer
carlos.rei...@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
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
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
On Tue, Aug 6, 2013 at 4:17 PM, Carlos Henrique Reimer
carlos.rei...@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
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
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
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
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
Shuo Liu [EMAIL PROTECTED] writes:
Whoa ... that is a whole lot more data than I'm used to seeing in
TopMemoryContext. How many stats dump lines are there exactly (from
here to the crash report)?
OK, I didn't know that was a surprise. There are about 600 stats dump lines
in between.
Well,
:
From: Tom Lane [mailto: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-general@postgresql.org
Date: Wed, 11 Jul 2007 15:33:41 -0400
Subject: Re: [GENERAL] exit code -1073741819
Shuo Liu [EMAIL PROTECTED] writes: Whoa ... that is a whole lot more data
than I'm used to seeing
Shuo Liu [EMAIL PROTECTED] writes:
Thank you so much for pointing out the problems. The first one seems very
silly :-(. For the second one, I may stay out of trouble if I don't use
transform() at all (I can tolerate some error without transform), am I right?
Hmm, I wouldn't suggest removing
Hi, All,
I'm working on a GIS project using PostgreSQL and PostGIS. In the project I
need to find locations of about 12K addresses (the process is referred to as
geocoding). I wrote some script to perform this task by calling a procedure
tiger_geocoding that is provided by PostGIS. My script
Shuo Liu [EMAIL PROTECTED] writes:
The log shows the following message:
CurTransactionContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExecutorState: 122880 total in 4 blocks; 1912 free (9 chunks); 120968 used
ExprContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
Hi, Tom,
Thanks for the reply. I'll try to provide as much information as I can.
ExecutorState: 122880 total in 4 blocks; 1912 free (9 chunks); 120968 used
ExprContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
ExprContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
Subject: Re: [GENERAL] exit code -1073741819
Shuo Liu [EMAIL PROTECTED] writes: The log shows the following message:
CurTransactionContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExecutorState: 122880 total in 4 blocks; 1912 free (9 chunks); 120968 used
ExprContext: 8192 total in 1
Shuo Liu [EMAIL PROTECTED] writes:
TopMemoryContext: 11550912 total in 1377 blocks; 123560 free (833 chunks);
11427352 used
Whoa ... that is a whole lot more data than I'm used to seeing in
TopMemoryContext. How many stats dump lines are there exactly (from
here to the crash report)? If
Shuo Liu [EMAIL PROTECTED] writes:
One more question. I'm new to PostgreSQL and not an expert in debugging.
After checking the manual, I think I need to turn on the following parameters
in order to generate debug info. Do you think doing so would give us what we
need to pinpoint the
Whoa ... that is a whole lot more data than I'm used to seeing in
TopMemoryContext. How many stats dump lines are there exactly (from
here to the crash report)?
OK, I didn't know that was a surprise. There are about 600 stats dump lines
in between.
The spatial database that the script is
OK, so maybe it's dependent on the size of the table. Try generating a
test case by loading up just your schema + functions + a lot of dummy
entries generated by script.
Is the data proprietary? If not, maybe you could arrange to send me a
dump off-list. A short test-case script would be
Shuo Liu [EMAIL PROTECTED] writes:
That's what I was planning to do. I'll generate a table with dummy entries. I
think we may try to use the smaller base table first. Once I can reproduce
the problem I'll dump the database into a file and send it to you. Is there a
server that I can upload
21 matches
Mail list logo
