Re: [GENERAL] Checkpoint request failed on version 8.2.1. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] Checkpoint request failed on version 8.2.1.
Date
Msg-id 145.1168573187@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] Checkpoint request failed on version 8.2.1.  ("Jim C. Nasby" <jim@nasby.net>)
Responses Re: [GENERAL] Checkpoint request failed on version 8.2.1.  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
"Jim C. Nasby" <jim@nasby.net> writes:
> On Thu, Jan 11, 2007 at 03:14:37PM -0500, Tom Lane wrote:
>> ... And anyway there should never
>> *be* a real permissions problem; if there is then the user's been poking
>> under the hood sufficient to void the warranty anyway ;-)

> Or some other "helpful" process such as a virus scanner has been poking
> under the hood for you... :(

One point worth making is that I'm not really convinced anymore that
we have proof that antivirus code has been creating any such problems.
We have several anecdotal cases where someone reported erratic
"permission denied" problems on Windows, and we suggested getting rid
of any AV code, and it seemed to fix their problem --- but how long did
they test?  This problem is inherently very timing-sensitive, and so the
fact that you don't see it for a little while is hardly proof that it's
gone.  See the report that started this thread for examples of apparent
correlations that are really quite spurious, like whether the test case
is being driven locally or not.  It could easy be that every report
we've heard really traces to the not-yet-deleted-file problem.

So basically what we'd have is that if you manually remove permissions
on a database file or directory you'd be risking data loss; but heck,
if you manually move, rename, delete such a file you're risking
(guaranteeing) data loss.  Any sane user is going to figure "keep your
fingers away from the moving parts"; or if he can't figure that out,
he's got no one but himself to blame.

It's not ideal, granted, but we're dealing with a much-less-than-ideal
OS, so we gotta make some compromises.

            regards, tom lane

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PERFORM] unusual performance for vac following 8.2upgrade
Next
From: Tom Lane
Date:
Subject: Re: Problem linking libecpg.5.3.dylib on OS X