failed to unlink, Permission denied

On 8/9/07, M S <arthur_ringworn@yahoo.co.uk> wrote:

I left our app on soak test overnight, it ran fine for some time but after a few hours I noticed the following messages repeated in the log (the tmp filename changes, but the PlPgSql function which causes it does not).
2007-08-08 17:25:57 LOG: failed to unlink "pg_tblspc/16403/16404/pgsql_tmp/pgsql_tmp5260.0": Permission denied

2007-08-08 17:25:57 CONTEXT: PL/pgSQL function "JobTargetNextUnsentGet" line 40 at for over select rows
The PlPgSql function is just a SELECT with 2 INNER JOINS, an integer comparison WHERE clause, with an ORDER BY time and a LIMIT 1.

Could anyone please suggest what could be behind this error?

I have checked the Changelog from 8.2.3-8.2.4 and nothing look relevant.

no, but (IMO) 8.2.4 is a required upgrade....so you should be testing that.

The server is unable to delete a file (specifically, a temporary
table created for sorting). Have you considered any running services
that may acquire a lock on the table (windows is famous for this).
This may also suggest you need to look at the work_mem setting, but
this is not the issue at hand.

is the error repeatable?

merlin

no, but (IMO) 8.2.4 is a required upgrade....so you should be testing

that.
Understood, I'll try an upgrade after my repeat tests have finished.

The server is unable to delete a file (specifically, a temporary
table created for sorting). Have you considered any running services
that may acquire a lock on the table (windows is famous for this).

There is the possibility of other threads inserting into the same table, but wouldn't that be a problem according to my understanding of MVCC. There are no LOCK TABLE statements on this table.
I can't think of any programs which would be locking the files (antivirus or other), but I'll have a look.

This may also suggest you need to look at the work_mem setting, but
this is not the issue at hand.

Interesting, I'll pass that on.

is the error repeatable?

I'm running the tests again with 8.2.3 to get an idea.

Cheers for the help!

___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/

I have reproduced this.

I'll upgrade to 8.2.4 and report back after my long weekend.

Cheers.

----- Original Message ----
From: M S <arthur_ringworn@yahoo.co.uk>
To: pgsql-general@postgresql.org
Sent: Thursday, 9 August, 2007 1:54:17 PM
Subject: Re: [GENERAL] failed to unlink, Permission denied

no, but (IMO) 8.2.4 is a required upgrade....so you should be testing

that.
Understood, I'll try an upgrade after my repeat tests have finished.

The server is unable to delete a file (specifically, a temporary
table created for sorting). Have you considered any running services
that may acquire a lock on the table (windows is famous for this).

There is the possibility of other threads inserting into the same table, but wouldn't that be a problem according to my understanding of MVCC. There are no LOCK TABLE statements on this table.
I can't think of any programs which would be locking the files (antivirus or other), but I'll have a look.

This may also suggest you need to look at the work_mem setting, but
this is not the issue at hand.

Interesting, I'll pass that on.

is the error repeatable?

I'm running the tests again with 8.2.3 to get an idea.

Cheers for the help!

___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/

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

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

___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/

M S <arthur_ringworn@yahoo.co.uk> writes:

I can't think of any programs which would be locking the files (antivirus o=
r other), but I'll have a look.

Since it's a temporary file, no other Postgres process would be touching
it. I strongly suspect an antivirus or similar tool is touching the
file just as we try to delete it.

regards, tom lane