BTW: what happens on Windows if we're trying to do the equivalent
of rm -rf database-dir and someone is holding open one of the
files
in the directory? Or has the directory itself open for readdir()?
For the first definity and I think for the second, when doing it from the
commandline,
[EMAIL PROTECTED]
Cc: Magnus Hagander [EMAIL PROTECTED];
pgsql-hackers@postgresql.org; Tom Lane [EMAIL PROTECTED]
Sent: Wednesday, January 17, 2007 4:44 PM
Subject: Re: [HACKERS] Idea for fixing the Windows fsync problem
Takayuki Tsunakawa wrote:
From: Tom Lane [EMAIL PROTECTED]
I wrote:
I've
Magnus Hagander [EMAIL PROTECTED] writes:
BTW: what happens on Windows if we're trying to do the equivalent
of rm -rf database-dir and someone is holding open one of the
files in the directory? Or has the directory itself open for readdir()?
For the first definity and I think for the second,
Takayuki Tsunakawa wrote:
Hello, Stefan-san
tom is talking about the postgresql distributed buildfarm:
http://buildfarm.postgresql.org/cgi-bin/show_status.pl
Thank you for telling me. This is a great system, isn't it?
yeah the buildfarm plays an important role in the development process
Checkpoint command here reported an error yesterday. If Tom-san's
patch is effective, it should not fail and no messages are put in the
event log.
I can confirm that the latest set of patches from Tom as in anoncvs now
fixes this. Checkpoint command succeeds and no error is logged on the
From: Tom Lane [EMAIL PROTECTED]
It's still not 100% bulletproof, because it's possible that some
other
backend is holding an open file in the database as a consequence of
having had to dump some shared buffer for itself, but that should be
pretty darn rare if the bgwriter is getting its job
Tom Lane wrote:
I just had a thought about fixing those Windows permission denied
problems. The case that we believe we understand is where the bgwriter
is trying to execute a previously-logged fsync request against a table
file that is pending delete --- that is, actually has been
Magnus Hagander [EMAIL PROTECTED] writes:
Perhaps we could have the bgwrite check the queue *if* it gets the
ENOENT/EACCESS error and then re-check the queue for drops on that file?
Hmm ... seems a bit ugly, but then again I've not been able to come up
with a nice way of making the backends
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
So: maybe the solution is to add a step to the drop sequence, namely
revoking any pending fsync request, before unlink.
Perhaps we could have the bgwrite check the queue *if* it gets the
ENOENT/EACCESS error and then re-check the
From: Tom Lane [EMAIL PROTECTED]
I suggested that here
http://archives.postgresql.org/pgsql-hackers/2007-01/msg00642.php
but have received no feedback about it ...
I'm sorry, I missed it.
From: Tom Lane [EMAIL PROTECTED]
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
So: maybe
I wrote:
I've committed a tentative patch along these lines to HEAD. Please
test.
So I come home from dinner out, and find the buildfarm all red :-(
I'm not sure why I didn't see this failure in my own testing, but in
hindsight it's quite obvious that if the bgwriter is to take a hard
line
From: Tom Lane [EMAIL PROTECTED]
I wrote:
I've committed a tentative patch along these lines to HEAD. Please
test.
So I come home from dinner out, and find the buildfarm all red :-(
I'm not sure why I didn't see this failure in my own testing, but in
hindsight it's quite obvious that if
Takayuki Tsunakawa wrote:
From: Tom Lane [EMAIL PROTECTED]
I wrote:
I've committed a tentative patch along these lines to HEAD. Please
test.
So I come home from dinner out, and find the buildfarm all red :-(
I'm not sure why I didn't see this failure in my own testing, but in
hindsight
I just had a thought about fixing those Windows permission denied
problems. The case that we believe we understand is where the bgwriter
is trying to execute a previously-logged fsync request against a table
file that is pending delete --- that is, actually has been unlink()'d,
but some other
14 matches
Mail list logo
