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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] Checkpoint request failed on version 8.2.1.
Дата
Msg-id 145.1168573187@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] Checkpoint request failed on version 8.2.1.  ("Jim C. Nasby" <jim@nasby.net>)
Ответы Re: [GENERAL] Checkpoint request failed on version 8.2.1.  (Magnus Hagander <magnus@hagander.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PERFORM] unusual performance for vac following 8.2upgrade
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Problem linking libecpg.5.3.dylib on OS X