I wrote:
> It might be interesting to think about not requiring the ControlFileLock
> to be held while making new WAL segments. I think the only reason it
> does that is to ensure that link/rename failure can be treated as a hard
> error (because no one could have beat us to the filename), but we'
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
It seems to me that it's not been included in b3. Tom?
I'm waiting for some report of whether it fixes the problems?
voilà:
Sent: Tuesday, October 31, 2006 7:23 AM
Subject: Re: [BUGS] xlog lockup patch (was: BUG #2712: could not fsync
segment:
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> It seems to me that it's not been included in b3. Tom?
I'm waiting for some report of whether it fixes the problems?
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'ki
It seems to me that it's not been included in b3. Tom?
//Magnus
> -Original Message-
> From: Thomas H. [mailto:[EMAIL PROTECTED]
> Sent: den 8 november 2006 12:59
> To: Magnus Hagander
> Cc: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #2712: could not fs
PM
Subject: RE: [BUGS] BUG #2712: could not fsync segment: Permission
Yeah, IIRC it was only for the xlog stuff.
//Magnus
-Original Message-
From: Thomas H. [mailto:[EMAIL PROTECTED]
Sent: den 30 oktober 2006 13:21
To: Magnus Hagander
Subject: Re: [BUGS] BUG #2712: could not fsync segm
uot;Magnus Hagander" <[EMAIL PROTECTED]>
To: "Tom Lane" <[EMAIL PROTECTED]>
Cc: "Peter Brant" <[EMAIL PROTECTED]>; "Thomas H."
<[EMAIL PROTECTED]>; ; "Bruce Momjian"
<[EMAIL PROTECTED]>
Sent: Sunday, October 29, 2006 6:10
> > I haven't reproduced this on my box. But if you can give me
> a patch to
> > try I can build binaries for Thomas to test, if he can do
> testing but
> > not building.
>
> Utterly untested ... BTW, why does pgrename have an #if to
> check either GetLastError() or errno, but pgunlink doesn'
It might be interesting to think about not requiring the ControlFileLock
to be held while making new WAL segments. I think the only reason it
does that is to ensure that link/rename failure can be treated as a hard
error (because no one could have beat us to the filename), but we're
already havin
"Thomas H." <[EMAIL PROTECTED]> writes:
> it is defenitely the writer process that blocks the db. but in every case
> the writer process seems to fail to rename the file due to another
> postgresql still holding a filehandle to the very xlog file that should be
> renamed.
Right, all you need is
As for fixing the problem we do understand: ISTM it's just an
awful idea for pgrename and pgunlink to be willing to loop
forever. I think they should time out and report the failure
after some reasonable period (say between 10 sec and a minute).
is the main problem realy in the rename/delete fu
Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > I haven't reproduced this on my box. But if you can give me a patch to
> > try I can build binaries for Thomas to test, if he can do testing but
> > not building.
>
> Utterly untested ... BTW, why does pgrename have an #if to chec
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> I haven't reproduced this on my box. But if you can give me a patch to
> try I can build binaries for Thomas to test, if he can do testing but
> not building.
Utterly untested ... BTW, why does pgrename have an #if to check
either GetLastError() or e
I'm not in a position to test this though. Magnus or Bruce?
I haven't reproduced this on my box. But if you can give me a patch to
try I can build binaries for Thomas to test, if he can do testing but
not building.
a binary would be marvelous. if too much hasle, i can setup a msvc++ 2005
h
> > The same problem exists in 8.1 too. See this thread
> > http://archives.postgresql.org/pgsql-bugs/2006-04/msg00177.php
> > Tom and Magnus tracked down a cause, but I don't think a
> fix was ever
> > implemented.
>
> Thomas seems to have two different issues there: the "could
> not rename
> > i've installed Filemon
> > (http://www.sysinternals.com/Utilities/Filemon.html)
> > now. this gives more insight what happens to the file.
> > ...
> > D:\DB\PostgreSQL-8.2\data\base\3964774\6422806 DELETE PEND Options:
> > Open
> > Access: 0012019F
>
> This is quite interesting, because it s
"Thomas H." <[EMAIL PROTECTED]> writes:
> i've installed Filemon (http://www.sysinternals.com/Utilities/Filemon.html)
> now. this gives more insight what happens to the file.
> ...
> D:\DB\PostgreSQL-8.2\data\base\3964774\6422806 DELETE PEND Options: Open
> Access: 0012019F
This is quite interes
The log messages you have don't make it clear which process is trying to
do the fsync, but I would expect it to be the bgwriter. (Possibly you
should modify log_line_prefix to include PID so we can tell a bit
better.)
you're right (as always :-)). its the "writer process" (pid 5196) that
outpu
"Thomas H." <[EMAIL PROTECTED]> writes:
>> Do you actually mean it's trying to write that file? Or is it just
>> sitting there holding the open filehandle?
> well, hard to tell :-)
> according to the log-messages i would assume it is *trying* to write.
The log messages you have don't make it cle
"Thomas H." <[EMAIL PROTECTED]> writes:
right now its PID 4844 ("\BaseNamedObjects\pgident: postgres: db_outnow
outnow1 127.0.0.1(2122) idle") that tries to write
"D:\DB\PostgreSQL-8.2\data\base\3964774\6422331"
Do you actually mean it's trying to write that file? Or is it just
sitting there h
"Thomas H." <[EMAIL PROTECTED]> writes:
> right now its PID 4844 ("\BaseNamedObjects\pgident: postgres: db_outnow
> outnow1 127.0.0.1(2122) idle") that tries to write
> "D:\DB\PostgreSQL-8.2\data\base\3964774\6422331"
Do you actually mean it's trying to write that file? Or is it just
sitting th
with process explorer i can actually check which postgres.exe instance
(in
all cases i've checked its just 1 instance, and always just 1 file) holds
the lock for the file in question.
So which one is it?
it's always one of the db-"slaves" and not "logger process", "stats
collector process" o
"Thomas H." <[EMAIL PROTECTED]> writes:
> with process explorer i can actually check which postgres.exe instance (in
> all cases i've checked its just 1 instance, and always just 1 file) holds
> the lock for the file in question.
So which one is it?
> the postgres instance that holds the lock e
Actually, now that I look back in the archives, I think we had theorized
that the fsync errors come from attempting to fsync a file that's
already been deleted but some backend still has a reference to.
Apparently that leads to EACCES instead of ENOENT (which the code is
already prepared to expect
"Peter Brant" <[EMAIL PROTECTED]> writes:
> FWIW, we were bitten by the fsync problem which you noticed too.
> Unfortunately we were never able to track down a cause (see the mailing
> list archives). They are separate problems though.
Actually, now that I look back in the archives, I think we h
Move to Linux. :-) In our case, everything but the database servers
were already Linux so it was an easy choice. Things have been rock
solid since then.
Once things get stuck, I don't think there is an alternative besides
"stop -m immediate". However, since the problem is caused by an idle
back
That might be one cause (or it might otherwise exacerbate the problem),
but it isn't the only cause. We weren't running anti-virus software and
neither is Thomas. Unfortunately with the last go around, we
collectively ran out of ideas before an underlying cause could be
identified.
Pete
>>> Tom
The same problem exists in 8.1 too. See this thread
its only appearing in 8.2 here, i've just rechecked our logs...
is there any workaround? how did you get around that problem of having a
total lockdown?
thanks,
thomas
"Thomas H." <[EMAIL PROTECTED]> 23.10.2006 18:21 >>>
there is defenit
"Peter Brant" <[EMAIL PROTECTED]> writes:
> The same problem exists in 8.1 too. See this thread
> http://archives.postgresql.org/pgsql-bugs/2006-04/msg00177.php
> Tom and Magnus tracked down a cause, but I don't think a fix was ever
> implemented.
Thomas seems to have two different issues there:
The same problem exists in 8.1 too. See this thread
http://archives.postgresql.org/pgsql-bugs/2006-04/msg00177.php
Tom and Magnus tracked down a cause, but I don't think a fix was ever
implemented.
FWIW, we were bitten by the fsync problem which you noticed too.
Unfortunately we were never ab
ners and the such)
running - 8.1 on the same box (even on same partition) run fine.
regarnds,
- thomas
- Original Message -
From: "Thomas H." <[EMAIL PROTECTED]>
To: "Tom Lane" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, October 23, 2006 11:52
unfortunately not.
and this is not happening with 8.1
regards,
thomas
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Thomas H" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, October 23, 2006 4:07 AM
Subject: Re: [BUGS] BUG #2712: could not
"Thomas H" <[EMAIL PROTECTED]> writes:
> Operating system: windows 2003 standard
> Description:could not fsync segment: Permission denied
The usual answer to this has been that you're running some
overenthusiastic antivirus software.
regards, tom lane
--
denied
2006-10-23 03:23:14 LOCATION: smgrsync, smgr.c:888
- thomas
- Original Message -
From: "Thomas H" <[EMAIL PROTECTED]>
To:
Sent: Monday, October 23, 2006 1:28 AM
Subject: [BUGS] BUG #2712: could not fsync segment: Permission denied
The following bug has be
The following bug has been logged online:
Bug reference: 2712
Logged by: Thomas H
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2b1
Operating system: windows 2003 standard
Description:could not fsync segment: Permission denied
Details:
sometimes we're seein
34 matches
Mail list logo
