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
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
36 matches
Mail list logo
