Re: "could not stat file "base/17436/119145": Permission denied" when performing pg_database_size() on windows with 8.4.0

Hello,

I have a Postgres 8.4.0 (I've been meaning to upgrade) server running
on Windows Vista:

Curiously, whenever I call pg_database_size, I get a cryptic error message:

SELECT pg_size_pretty(pg_database_size('my_database'))

ERROR: could not stat file "base/17436/119145": Permission denied

********** Error **********

ERROR: could not stat file "base/17436/119145": Permission denied
SQL state: 42501

Why? What should I do, other than the obvious, upgrading to 8.4.2?

Regards,
Peter Geoghegan

Hello,

On Sat, 30 Jan 2010 00:12:54 +0000 Peter Geoghegan wrote:

> I have a Postgres 8.4.0 (I've been meaning to upgrade) server running
> on Windows Vista:
>
> Curiously, whenever I call pg_database_size, I get a cryptic error
> message:
>
> SELECT pg_size_pretty(pg_database_size('my_database'))
>
> ERROR: could not stat file "base/17436/119145": Permission denied

This is not really a PostgreSQL-problem. The permissions for this
file/directory (and probably some more) are incorrect. The database
user (usually named "postgres") must own this files.

> Why? What should I do, other than the obvious, upgrading to 8.4.2?

Fix the permissions.

Bye

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project

On Sat, 2010-01-30 at 00:12 +0000, Peter Geoghegan wrote:
> Hello,
>
> I have a Postgres 8.4.0 (I've been meaning to upgrade) server running
> on Windows Vista:
>
> Curiously, whenever I call pg_database_size, I get a cryptic error message:
>
> SELECT pg_size_pretty(pg_database_size('my_database'))
>
> ERROR: could not stat file "base/17436/119145": Permission denied
>
>
> ********** Error **********
>
> ERROR: could not stat file "base/17436/119145": Permission denied
> SQL state: 42501
>
> Why? What should I do, other than the obvious, upgrading to 8.4.2?

Well generally this would mean that your postgres user can't read that
file. Make sure that your permissions are correct in the subdirectories.

Joshua D. Drake

>
> Regards,
> Peter Geoghegan
>

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.

Hi Joshua,

> Well generally this would mean that your postgres user can't read that
> file. Make sure that your permissions are correct in the subdirectories.

Funnily enough, the problem comes and goes without any intervention
from me. It works fine right now.

Regards,
Peter Geoghegan

Peter Geoghegan wrote:
> Hi Joshua,
>
>> Well generally this would mean that your postgres user can't read that
>> file. Make sure that your permissions are correct in the subdirectories.
>
> Funnily enough, the problem comes and goes without any intervention
> from me. It works fine right now.

that is usually caused by missbehaving antovirussoftware that tries to
do "on-access" scanning. Try excluding PGDATA from whatever you have
there - or even better deinstall...

Stefan

Hi Stefan,

> that is usually caused by missbehaving antovirussoftware that tries to do
> "on-access" scanning. Try excluding PGDATA from whatever you have there - or
> even better deinstall...

It may well be misbehaving anti-virus software (this machine is not a
dedicated database server). I've added an exclusion rule to PGDATA.

Thanks,
Peter Geoghegan

On Sun, Jan 31, 2010 at 17:05, Peter Geoghegan
<peter(dot)geoghegan86(at)gmail(dot)com> wrote:
> Hi Stefan,
>
>> that is usually caused by missbehaving antovirussoftware that tries to do
>> "on-access" scanning. Try excluding PGDATA from whatever you have there - or
>> even better deinstall...
>
> It may well be misbehaving anti-virus software (this machine is not a
> dedicated database server). I've added an exclusion rule to PGDATA.

Please note that it is quite often not enough to just add the
exclusion - you may need to uninstall it.

That said, starting with an exclusion is a good thing. Which is not
pg-specific at all - I un-fondly recall two instances of antirivus
deciding it knows how to clean a virus out of a SQL Server database
file.. Yeah, fun was ensured...

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Hi Magnus,

Good to hear from you. You'll recall that I sat at your table the
evening of pgday.eu '09.

> Please note that it is quite often not enough to just add the
> exclusion - you may need to uninstall it.
>
> That said, starting with an exclusion is a good thing. Which is not
> pg-specific at all - I un-fondly recall two instances of antirivus
> deciding it knows how to clean a virus out of a SQL Server database
> file.. Yeah, fun was ensured...

Yes, but a worm propagating itself around the world with a database
server as its vector is an MS SQL server specific issue. :-)

Everything seems fine now. I guess I'll just wait and see if I
experience any more problems.

Regards,
Peter Geoghegan