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

Now it seems as though the database is somehow diseased. I can select and
insert data in all of the other tables in the database but I can not
create tables:

# create table test_tab (idfield int);
ERROR: cannot create test_tab: Permission denied

I also can not dump data out of ev_log:

pg_dump: ERROR: cannot count blocks for ev_log -- open failed: Permission
denied
pg_dump: lost synchronization with server, resetting connection
pg_dump: SQL command to dump the contents of table "ev_log" failed:
PQendcopy() failed.
pg_dump: Error message from server: pg_dump: The command was: COPY
public.ev_log (logid, eventtype, username, ipaddress, eventdata, ts) TO
stdout;

Any ideas?

I'm willing to dump and reload, but I'd like to get the data out of the
log table if possible.

-Zeki


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

zeki@mokhtarzada.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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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.

Thanks!

-Zeki

Tom Lane wrote:

>zeki@mokhtarzada.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
>
>


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Tue, Aug 23, 2005 at 11:06:44AM -0400, Zeki Mokhtarzada wrote:
> 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.

Probably, this is because on other tables you do not need to create new
segments, while the ev_log table is big enough to need some.

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"People get annoyed when you try to debug them." (Larry Wall)

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster