Re: [HACKERS] Checkpoint request failed on version 8.2.1.

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, Patrick Earl <patearl(at)patearl(dot)net>, pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Checkpoint request failed on version 8.2.1.
Date: 2007-01-12 14:31:19
Message-ID: 20070112143119.GC6561@svr2.hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Thu, Jan 11, 2007 at 10:39:47PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <jim(at)nasby(dot)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 do. I have positive proof of this being caused by AV software.

I don't know that it has been the problem in *all cases*, certainly, but
I've had kernel stacktraces pointing into AV filter drivers more than
once.

> 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.

No, not all of them. But certainly a fair share of them can have been.

> 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.

That was the point I was trying tom ake erarlier :-)

//Magnus

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2007-01-12 14:33:57 Re: [HACKERS] Checkpoint request failed on version 8.2.1.
Previous Message Magnus Hagander 2007-01-12 14:28:51 Re: [HACKERS] Checkpoint request failed on version 8.2.1.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-01-12 14:33:57 Re: [HACKERS] Checkpoint request failed on version 8.2.1.
Previous Message Magnus Hagander 2007-01-12 14:28:51 Re: [HACKERS] Checkpoint request failed on version 8.2.1.