Hello All,
Getting *ERROR: XX001: could not read block 17 of relation
base/16386/2619: read only 0 of 8192 bytes*, While vacuuming database
Manual vacuuming and Auto vacuuming process *constantly* taking high
CPU, not able to skip corrupted table for vacuuming and dump this
message
Siddharth Shah siddharth.s...@elitecore.com wrote:
* fsync is off*
If you are running the database with fsync off and there is any sort
of unusual termination, your database will probably be corrupted. I
recommend restoring from your last good backup. If you don't have
one, recovery is
Thanks Kevin.
Yes, I installed 8.4.3 then I have found that DDL and DML statements
were getting failed to execute in some distributions
So that's why taken call for reindexing
What can be the method to verify that it's a database corruption ?
xdb=# \dt;
ERROR: index
[rearranged to put the most critical point first]
Siddharth Shah siddharth.s...@elitecore.com wrote:
I don't have any backup available, Is there any way to fix this ?
I *strongly* recommend that you shut down the database and take a
file copy of the whole data tree (everything under what -D
Kevin Grittner wrote:
[rearranged to put the most critical point first]
Siddharth Shah siddharth.s...@elitecore.com wrote:
I don't have any backup available, Is there any way to fix this ?
I *strongly* recommend that you shut down the database and take a
file copy of the whole
One more point, This is observed two times while product firmware
updates which updates Postgres 8.4.3 from 8.4.1
Abruptly shutdown never leads to this type of corruption while fsync is
always off
Thanks,
Siddharth
Siddharth Shah wrote:
Kevin Grittner wrote:
[rearranged to put the most
Siddharth Shah siddharth.s...@elitecore.com wrote:
xdb=# reindex index pg_class_relname_nsp_index;
Now INDEXing taking High CPU and postgres baffled.
consider doing your recovery in single-user mode
postgres --single -P -D $DATADIR -p 5433 xdb
Same behavior in single mode.
Kevin Grittner wrote:
Siddharth Shah siddharth.s...@elitecore.com wrote:
xdb=# reindex index pg_class_relname_nsp_index;
Now INDEXing taking High CPU and postgres baffled.
consider doing your recovery in single-user mode
postgres --single -P -D $DATADIR -p
Siddharth Shah siddharth.s...@elitecore.com writes:
PID PPID USER STAT VSZ %MEM %CPU COMMAND
13419 13418 nobody R39172 8% 99% postgres --single -P -D
/var/db -p 5433 xdb
It's been running from 10 minutes still there is no output or logs.
What does strace show that process
