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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
Cc: 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 03:39:47
Message-ID: 145.1168573187@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2007-01-12 04:37:19 Re: Corrupt database? 8.1/FreeBSD6.0
Previous Message Tom Lane 2007-01-12 03:27:39 Re: RESTORE Error

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-01-12 03:47:32 Re: Problem linking libecpg.5.3.dylib on OS X
Previous Message Jeff Amiel 2007-01-12 03:06:47 Re: Corrupt database? 8.1/FreeBSD6.0