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 it
> 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
se
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 p
"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
ROTECTED]>
To: "Takayuki Tsunakawa" <[EMAIL PROTECTED]>
Cc: "Magnus Hagander" <[EMAIL PROTECTED]>;
; "Tom Lane" <[EMAIL PROTECTED]>
Sent: Wednesday, January 17, 2007 4:44 PM
Subject: Re: [HACKERS] Idea for fixing the Windows fsync problem
>
> 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
command
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, bu
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 obvio
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 a
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
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
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
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 unlin
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 pr
14 matches
Mail list logo
