Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
And actually, when I look at the API docs, our case now seems to be
documented. Or am I misreading our situation. I have:
"If you call CreateFile on a file that is pending deletion as a result
of a previous call to DeleteF
On Tue, Jan 16, 2007 at 11:11:59AM -0500, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > And actually, when I look at the API docs, our case now seems to be
> > documented. Or am I misreading our situation. I have:
>
> > "If you call CreateFile on a file that is pending deletion
Magnus Hagander <[EMAIL PROTECTED]> writes:
> And actually, when I look at the API docs, our case now seems to be
> documented. Or am I misreading our situation. I have:
> "If you call CreateFile on a file that is pending deletion as a result
> of a previous call to DeleteFile, the function fails.
On Tue, Jan 16, 2007 at 10:20:04AM +0900, Takayuki Tsunakawa wrote:
> From: "Magnus Hagander" <[EMAIL PROTECTED]>
> > But yeah, that's probably a good idea. A quick look at the code says
> we
> > should at least ask people who have this problem to give it a run
> with
> > logging at DEBUG5 which sh
"Takayuki Tsunakawa" <[EMAIL PROTECTED]> writes:
> BTW, why does the bgwriter try to open and write the pages of already
> dropped relations?
It does not; the problem is with stale fsync requests.
> If the relation being dropeed has
> already been registered in the list of files to be fsynced, is
From: "Magnus Hagander" <[EMAIL PROTECTED]>
> But yeah, that's probably a good idea. A quick look at the code says
we
> should at least ask people who have this problem to give it a run
with
> logging at DEBUG5 which should then log exactly what the errorcode
was.
> Or are you seeing more places th
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> DEBUG5 is going to be a bit voluminous, but let's try that if we can.
> Perhaps we should switch down the DEBUG level of it, at least until we
> know what happens?
That would have to wait on another update release, or at least someo
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> But yeah, that's probably a good idea. A quick look at the code says we
>> should at least ask people who have this problem to give it a run with
>> logging at DEBUG5 which should then log exactly what the errorcode was.
>> Or are you
Magnus Hagander <[EMAIL PROTECTED]> writes:
> But yeah, that's probably a good idea. A quick look at the code says we
> should at least ask people who have this problem to give it a run with
> logging at DEBUG5 which should then log exactly what the errorcode was.
> Or are you seeing more places th
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> pg_control is certainly not ever deleted or renamed, and in fact I
>>> believe there's an LWLock enforcing that only one PG process at a time
>>> is even touching it. So we need another theory to explain this one
On Thu, Jan 11, 2007 at 06:04:56PM -0500, Andrew Dunstan wrote:
> Please don't. At least not on the PostgreSQL web site nor in the docs.
> And no, I don't run my production servers on Windows either.
>
> For good or ill, we made a decision years ago to do a proper Windows
> port. I think that it
Scott Ribe <[EMAIL PROTECTED]> writes:
> Note when it happens, and if it doesn't succeed for some value of "too
> long", at least escalate to ERROR message, possibly fail.
ERROR and "fail" are the same thing. We could do this, and it wouldn't
even be much code, but it doesn't seem to address the
> Comments?
Note when it happens, and if it doesn't succeed for some value of "too
long", at least escalate to ERROR message, possibly fail.
--
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 722-0567 voice
---(end of broadcast)--
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> pg_control is certainly not ever deleted or renamed, and in fact I
>> believe there's an LWLock enforcing that only one PG process at a time
>> is even touching it. So we need another theory to explain this one :-(
> Right. What we
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Actually, it could still be the same problem, with the AV software only
>>> involved to the extent that it's trying to scan files for viruses.
>
>> Partially the same, but I've seen AV software keeping it open for
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Actually, it could still be the same problem, with the AV software only
>> involved to the extent that it's trying to scan files for viruses.
> Partially the same, but I've seen AV software keeping it open for
> hours... Basically un
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> On Fri, Jan 12, 2007 at 09:47:55AM -0500, Tom Lane wrote:
>>> No, I didn't claim that Windows AV software is bug-free ;-). What I
>>> said was that I'm not certain it's related to the "permission denied"
>>> reports, as opposed to ot
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Fri, Jan 12, 2007 at 09:47:55AM -0500, Tom Lane wrote:
>> No, I didn't claim that Windows AV software is bug-free ;-). What I
>> said was that I'm not certain it's related to the "permission denied"
>> reports, as opposed to other problems. Or are
On Fri, Jan 12, 2007 at 09:47:55AM -0500, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > On Thu, Jan 11, 2007 at 10:39:47PM -0500, Tom Lane wrote:
> >> One point worth making is that I'm not really convinced anymore that
> >> we have proof that antivirus code has been creating an
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Thu, Jan 11, 2007 at 10:39:47PM -0500, Tom Lane wrote:
>> 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 do. I have positive proof of this being cau
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
> It seems the win unlink is not implemented correctly and we need to
> replace it.
Easier said than done ...
regards, tom lane
---(end of broadcast)---
TIP 9: In vers
On Thu, Jan 11, 2007 at 10:39:47PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> 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 ho
On Fri, Jan 12, 2007 at 10:49:53AM +0100, Zeugswetter Andreas ADI SD wrote:
>
> > > I find it very unlikely that you would "during normal operations"
> end up
> > > in a situation where you would first have permissions to create
> files in
> > > a directory, and then lose them.
> > > What could be
> > I find it very unlikely that you would "during normal operations"
end up
> > in a situation where you would first have permissions to create
files in
> > a directory, and then lose them.
> > What could be is that you have a directory where you never had
> > permissions to create the file in th
"Jim C. Nasby" <[EMAIL PROTECTED]> 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 "help
On Thu, 2007-01-11 at 21:42 -0300, Alvaro Herrera wrote:
> Joshua D. Drake wrote:
>
> > > Please don't. At least not on the PostgreSQL web site nor in the docs.
> > > And no, I don't run my production servers on Windows either.
> >
> > It does seem like it might be a good idea to have FAQs based
On Thu, Jan 11, 2007 at 09:42:38PM -0300, Alvaro Herrera wrote:
>
> But we have per-platform FAQs. If there is information missing, the
> reason is that nobody has submitted an appropriate patch, nothing more.
>
where are these FAQs, and why were they not easily found when the original
poster s
Joshua D. Drake wrote:
> > Please don't. At least not on the PostgreSQL web site nor in the docs.
> > And no, I don't run my production servers on Windows either.
>
> It does seem like it might be a good idea to have FAQs based on each OS,
> yes? There are various things that effect each OS diff
On Thu, Jan 11, 2007 at 03:12:07PM -0800, Joshua D. Drake wrote:
> It does seem like it might be a good idea to have FAQs based on each OS,
> yes? There are various things that effect each OS differently. The most
> obvious to me being shared memory and wal_sync_method.
>
> If could be a good idea
> >
> >
> >
>
>
> Please don't. At least not on the PostgreSQL web site nor in the docs.
> And no, I don't run my production servers on Windows either.
It does seem like it might be a good idea to have FAQs based on each OS,
yes? There are various things that effect each OS differently. The
Richard Troy wrote:
On Thu, 11 Jan 2007, Tom Lane wrote:
...snip...
(You know, of course, that my opinion is that no sane person would run a
production database on Windows in the first place. So the data-loss
risk to me seems less of a problem than the unexpected-failures problem.
It's not
On Thu, 11 Jan 2007, Tom Lane wrote:
...snip...
>
> (You know, of course, that my opinion is that no sane person would run a
> production database on Windows in the first place. So the data-loss
> risk to me seems less of a problem than the unexpected-failures problem.
> It's not like there aren
On Thu, Jan 11, 2007 at 04:32:42PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Given that this could result in data loss, if this was to be done I'd
> > very much want to see a way to disable it in a production environment.
>
> Production environments are the same ones
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> I find it very unlikely that you would "during normal operations" end up
>> in a situation where you would first have permissions to create files in
>> a directory, and then lose them.
>> What could be is that you have a directory whe
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Given that this could result in data loss, if this was to be done I'd
> very much want to see a way to disable it in a production environment.
Production environments are the same ones that won't be happy with
random checkpoint failures, either.
If we
On Thu, Jan 11, 2007 at 03:14:37PM -0500, Tom Lane wrote:
> The downside of this is that a real EACCES problem wouldn't get noted at
> any level higher than LOG, and so you could theoretically lose data
> without much warning. But I'm not seeing anything else we could do
> about it --- AFAIK we ha
Magnus Hagander <[EMAIL PROTECTED]> writes:
> I find it very unlikely that you would "during normal operations" end up
> in a situation where you would first have permissions to create files in
> a directory, and then lose them.
> What could be is that you have a directory where you never had
> per
Tom Lane wrote:
> "Patrick Earl" <[EMAIL PROTECTED]> writes:
>> In any case, the unit tests remove all contents and schema within the
>> database before starting, and they remove the tables they create as
>> they proceed. Certainly there are many things have been recently
>> deleted.
>
> Yeah, I
"Patrick Earl" <[EMAIL PROTECTED]> writes:
> In any case, the unit tests remove all contents and schema within the
> database before starting, and they remove the tables they create as
> they proceed. Certainly there are many things have been recently
> deleted.
Yeah, I think then there's no ques
There is no antivirus software running on the machine.
I'm not entirely sure how to determine which relation it is
complaining about. I see a folder that corresponds to the middle
number in the log, and I see numbers in the same range as the right
number from the log.
In any case, the unit test
"Patrick Earl" <[EMAIL PROTECTED]> writes:
> We're getting the error as part of an automated test suite and it is
> seems to occur every time the suite is run. The platform is Win XP 64
> bit.
Hm. We've seen problems of this ilk caused by bogus antivirus software,
but if that were the explanatio
We're getting the error as part of an automated test suite and it is
seems to occur every time the suite is run. The platform is Win XP 64
bit.
When running the same unit test suite from a remote machine, the error
does not occur. The error also does not occur when manually running
the create d
"Patrick Earl" <[EMAIL PROTECTED]> writes:
> 2007-01-11 09:56:17 ERROR: could not open relation 1663/16403/16426:
> Permission denied
> 2007-01-11 09:56:17 ERROR: checkpoint request failed
> 2007-01-11 09:56:17 HINT: Consult recent messages in the server log
> for details.
> 2007-01-11 09:56:17
Hi all. I'm getting a checkpoint request failed message when I try to
execute a CREATE DATABASE command. Since it was a fresh install, I've
included the entire server log up to the point of the error. I
truncated the log output two lines after the error message.
Is there a way I can avoid this
44 matches
Mail list logo