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 should then
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. The
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 as a
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
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 :-(
Right.
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 that
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 seeing
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 someone
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 that need
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, isn't it
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 the first
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 is that you
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 hood sufficient
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 3: Have you
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 caused by
I 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 is that you have a directory where you never had
permissions to create the file in
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 any such
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 your stack
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 other problems.
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 until
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
hours...
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 need is a
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's
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 question
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
permissions
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 where you never
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 that won't
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't a
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
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 most
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 to
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
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 sent
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 each
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 helpful process
35 matches
Mail list logo
