![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
Hello all, I woke up this morning and found my installation of Postgres (7.3.2) spewing the following error message: ERROR: cannot count blocks for ev_log -- open failed: Permission denied ERROR: cannot count blocks for ev_log -- open failed: Permission denied ERROR: cannot count blocks for ev_log -- open failed: Permission denied ERROR: cannot count blocks for ev_log -- open failed: Permission denied |
#3
| |||
| |||
|
|
zeki (AT) mokhtarzada (DOT) com writes: Hello all, I woke up this morning and found my installation of Postgres (7.3.2) spewing the following error message: ERROR: cannot count blocks for ev_log -- open failed: Permission denied ERROR: cannot count blocks for ev_log -- open failed: Permission denied ERROR: cannot count blocks for ev_log -- open failed: Permission denied ERROR: cannot count blocks for ev_log -- open failed: Permission denied Look around in the database directory. It kinda looks like one or more files or directories had had its ownership or permissions changed so that the server can't read it anymore. Postgres itself would not do such a thing, so the culprit is either administrator error or flaky disk hardware. After you fix the problem by hand, you'll want to try to figure out which. regards, tom lane |
#4
| |||
| |||
|
|
Very interesting... We recently changed the location of the data files using a symbolic link. Although all of the files had the correct ownership, the new parent directory was not owned by postgres. The strange thing is that we have been running like this for over a week, and even now, only the log table was effected (the log table is the only table that has a large number of data changing, most of the other tables are relatively static). Changing the owner of the parent directory to postgres fixed the problem. |
![]() |
| Thread Tools | |
| Display Modes | |
| |