Re: invalid memory alloc request size 1765277700 Error Question - Mailing list pgsql-general
From | Naoko Reeves |
---|---|
Subject | Re: invalid memory alloc request size 1765277700 Error Question |
Date | |
Msg-id | CAGoos17qpVc8Wix2GVc3LRSE5Xw4hZ+zDv+M3+rbQDtu76YpUA@mail.gmail.com Whole thread Raw |
In response to | Re: invalid memory alloc request size 1765277700 Error Question (Scott Marlowe <scott.marlowe@gmail.com>) |
List | pgsql-general |
Tom, Scott,
Thank you very much for your advice and right questions that lead to me the solution - In summary, I was able to identify and delete all corrupted data with no data loss. Everything add up once I disabled index per Tom's advice.
Here is the detail report:
Review the data again in order to answer Scott's questions. Both shows that it use index:
EXPLAIN SELECT * FROM table ORDER BY table_key OFFSET 526199 LIMIT 1;
"Limit (cost=42574.62..42574.70 rows=1 width=220)"
" -> Index Scan using table_pkey on table (cost=0.00..118098.91 rows=1459638 width=220)"
EXPLAIN SELECT * FROM table WHERE table_key = 304458;
"Index Scan using table_pkey on table (cost=0.00..7.38 rows=1 width=220)"
" Index Cond: (table_key = 304458)"
The columns I was able to review were up to 5th columns, including anything after that would shows data corruptions. Column types are varied (varchar, boolean, text, integer)
As soon as disabled Index per Tom's advice, everything became clear and make sense.
SELECT table_key FROM table GROUP BY table_key HAVING count(table_key) > 1
Returned 5 rows. Before disabling index, it returned 0 row.
The I performed the following query to identify exactly what record to delete:
SELECT * FROM table WHERE table_key=304458 -- error
SELECT ctid FROM table WHERE table_key=304458 -- (2021,22) (17958,10)
SELECT * FROM table WHERE ctid='(2021,22)' -- GOOD
SELECT * FROM table WHERE ctid='(17958,10)' -- BAD ERROR: invalid memory alloc request size 1765277700
Removed all bad records and I was finally able to REINDEX & pg_dump! Now everything looks VERY HAPPY.
One thing I failed to report/notice earlier is that there were 2 type of errors:
Some rows returned ERROR: invalid memory alloc request size 1765277700
Some rows returned ERROR: compressed data is corrupt
Thank you so much again for all your help.
- Naoko
--
Naoko Reeves
Thank you very much for your advice and right questions that lead to me the solution - In summary, I was able to identify and delete all corrupted data with no data loss. Everything add up once I disabled index per Tom's advice.
Here is the detail report:
Review the data again in order to answer Scott's questions. Both shows that it use index:
EXPLAIN SELECT * FROM table ORDER BY table_key OFFSET 526199 LIMIT 1;
"Limit (cost=42574.62..42574.70 rows=1 width=220)"
" -> Index Scan using table_pkey on table (cost=0.00..118098.91 rows=1459638 width=220)"
EXPLAIN SELECT * FROM table WHERE table_key = 304458;
"Index Scan using table_pkey on table (cost=0.00..7.38 rows=1 width=220)"
" Index Cond: (table_key = 304458)"
The columns I was able to review were up to 5th columns, including anything after that would shows data corruptions. Column types are varied (varchar, boolean, text, integer)
As soon as disabled Index per Tom's advice, everything became clear and make sense.
SELECT table_key FROM table GROUP BY table_key HAVING count(table_key) > 1
Returned 5 rows. Before disabling index, it returned 0 row.
The I performed the following query to identify exactly what record to delete:
SELECT * FROM table WHERE table_key=304458 -- error
SELECT ctid FROM table WHERE table_key=304458 -- (2021,22) (17958,10)
SELECT * FROM table WHERE ctid='(2021,22)' -- GOOD
SELECT * FROM table WHERE ctid='(17958,10)' -- BAD ERROR: invalid memory alloc request size 1765277700
Removed all bad records and I was finally able to REINDEX & pg_dump! Now everything looks VERY HAPPY.
One thing I failed to report/notice earlier is that there were 2 type of errors:
Some rows returned ERROR: invalid memory alloc request size 1765277700
Some rows returned ERROR: compressed data is corrupt
Thank you so much again for all your help.
- Naoko
On Fri, Feb 24, 2012 at 1:25 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
On Fri, Feb 24, 2012 at 4:01 AM, Naoko Reeves <naokoreeves@gmail.com> wrote:Are you certain that offset 526199 is using both the same query plan
> -- I have narrowed down the row
> SELECT * FROM table ORDER BY table_id OFFSET 526199 LIMIT 1 -- ERROR:
> invalid memory alloc request size 1765277700
and doesn't produce this error?If you do select <col_list> from table
> -- I was able to view a few columns
> SELECT table_id, table_column1, table_column2 FROm table ORDER BY table_id
> OFFSET 526199 LIMIT 1 -- returns one row table_id = 12345
> -- using that id to SELECT ALL. It shows fine...I was assuming this will
> give me same error...
> SELECT * FROM table WHERE table_id=12345 -- shows perfectly
> -- This also returns value just fine
> SELECT table_column3 FROM table WHERE table_id = 12345
> -- However this returns an error
> SELECT table_column3 FROm table ORDER BY table_id OFFSET 526199 LIMIT 1
> --error ERROR: invalid memory alloc request size 1765277700
where col_list is all cols except col3 do you get the error? What
type of col is col3?
--
Naoko Reeves
pgsql-general by date: