On Fri, Dec 21, 2007 at 01:30:07AM -0500, Jaime Casanova wrote:
On Dec 20, 2007 9:31 PM, Alvaro Herrera [EMAIL PROTECTED] wrote:
Jaime Casanova escribió:
it doesn't compile on current head on mingw 5.1 and msys 1.0.10; of
course, it doesn't compile on 8.2 neither in order to Alvaro's
Andrew Dunstan escribió:
Alvaro Herrera wrote:
I think this patch should fix it. I think win32.mak needs to be
similarly patched.
Don't you also need to add pgsleep.o to $(OBJS) in the win32 stanza?
Hmm. Wow, that's silly. I introduced a hack in a Replicator's Makefile
to avoid having
On Wed, Dec 19, 2007 at 07:50:29PM -0500, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Updated version attached. Comments on the wording of the messages are also
welcome ;-)
Well, since you asked ;-) ... I don't particularly like this.
Well, it's better to have you say that
On Thu, Dec 20, 2007 at 09:32:38AM +0100, Magnus Hagander wrote:
(errmsg(could not open file \%s\: %s violation, fileName,
(GetLastError() ==
ERROR_SHARING_VIOLATION)?_(sharing):_(lock)),
Is _() the proper way to get a translatable string in like that, or is
there a better way?
On 12/20/07, Magnus Hagander [EMAIL PROTECTED] wrote:
ereport(WARNING,
(errmsg(could not open file \%s\: %s violation, fileName,
(GetLastError() ==
ERROR_SHARING_VIOLATION)?_(sharing):_(lock)),
errdetail(Continuing to retry for 30 seconds.),
errhint(You may
On Thu, Dec 20, 2007 at 04:39:55AM -0800, Trevor Talbot wrote:
On 12/20/07, Magnus Hagander [EMAIL PROTECTED] wrote:
ereport(WARNING,
(errmsg(could not open file \%s\: %s violation, fileName,
(GetLastError() ==
ERROR_SHARING_VIOLATION)?_(sharing):_(lock)),
On 12/20/07, Magnus Hagander [EMAIL PROTECTED] wrote:
On Thu, Dec 20, 2007 at 04:39:55AM -0800, Trevor Talbot wrote:
On 12/20/07, Magnus Hagander [EMAIL PROTECTED] wrote:
ereport(WARNING,
(errmsg(could not open file \%s\: %s violation, fileName,
(GetLastError() ==
Trevor Talbot escribió:
Without looking myself, is it possible for errhint() or errdetail() to
do something that affects GetLastError()? It's like errno, checking it
very far away from the call site makes me nervous.
Yeah, they call gettext(), palloc/pfree/pstrdup and various StringInfo
On Thu, Dec 20, 2007 at 04:47:33AM -0800, Trevor Talbot wrote:
On 12/20/07, Magnus Hagander [EMAIL PROTECTED] wrote:
On Thu, Dec 20, 2007 at 04:39:55AM -0800, Trevor Talbot wrote:
On 12/20/07, Magnus Hagander [EMAIL PROTECTED] wrote:
ereport(WARNING,
(errmsg(could not open file
On Thu, Dec 20, 2007 at 10:26:46AM -0500, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Dec 19, 2007 at 07:50:29PM -0500, Tom Lane wrote:
2. Do we really want this to be WARNING? LOG seems a better idea,
since it's not warning about anything the client app did wrong.
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Dec 19, 2007 at 07:50:29PM -0500, Tom Lane wrote:
2. Do we really want this to be WARNING? LOG seems a better idea,
since it's not warning about anything the client app did wrong.
I put it as warning because I wanted to be sure the admin
On Thu, Dec 20, 2007 at 10:11:10AM -0500, Tom Lane wrote:
Trevor Talbot [EMAIL PROTECTED] writes:
Without looking myself, is it possible for errhint() or errdetail() to
do something that affects GetLastError()?
Hmm ... the macro framework is designed so that the arguments get
evaluated
Magnus Hagander [EMAIL PROTECTED] writes:
On Thu, Dec 20, 2007 at 10:11:10AM -0500, Tom Lane wrote:
BTW, I concur with Martijn's comment to avoid constructing phrases from
spare parts; it creates a translation problem, and in this case you'd
only be saving a few bytes anyway.
Ok. Are you
On 12/20/07, Magnus Hagander [EMAIL PROTECTED] wrote:
On Thu, Dec 20, 2007 at 04:39:55AM -0800, Trevor Talbot wrote:
On 12/20/07, Magnus Hagander [EMAIL PROTECTED] wrote:
ereport(WARNING,
(errmsg(could not open file \%s\: %s violation, fileName,
(GetLastError() ==
Trevor Talbot [EMAIL PROTECTED] writes:
Without looking myself, is it possible for errhint() or errdetail() to
do something that affects GetLastError()?
Hmm ... the macro framework is designed so that the arguments get
evaluated before anything very interesting happens, but it might be
better
On Thu, Dec 20, 2007 at 07:57:23AM -0800, Trevor Talbot wrote:
I'd expect the compiler to optimize away those, but I'll make it a var
anyawy.
It can't; it's an opaque callout to kernel32.dll, and there's nothing
that tells the optimizer when you can expect to get the same result.
That
Magnus Hagander wrote:
On Thu, Dec 20, 2007 at 10:26:46AM -0500, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Dec 19, 2007 at 07:50:29PM -0500, Tom Lane wrote:
2. Do we really want this to be WARNING? LOG seems a better idea,
since it's not warning about anything the
On Dec 20, 2007 3:29 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Magnus Hagander wrote:
On Thu, Dec 20, 2007 at 10:26:46AM -0500, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Dec 19, 2007 at 07:50:29PM -0500, Tom Lane wrote:
2. Do we really want this to be WARNING?
Jaime Casanova escribió:
it doesn't compile on current head on mingw 5.1 and msys 1.0.10; of
course, it doesn't compile on 8.2 neither in order to Alvaro's contact
to test it
Yeah, the buildfarm is failing in the same way.
Jaime Casanova escribió:
it doesn't compile on current head on mingw 5.1 and msys 1.0.10; of
course, it doesn't compile on 8.2 neither in order to Alvaro's contact
to test it
I think this patch should fix it. I think win32.mak needs to be
similarly patched.
--
Alvaro Herrera
Alvaro Herrera wrote:
Jaime Casanova escribió:
it doesn't compile on current head on mingw 5.1 and msys 1.0.10; of
course, it doesn't compile on 8.2 neither in order to Alvaro's contact
to test it
I think this patch should fix it. I think win32.mak needs to be
similarly patched.
On Dec 20, 2007 9:31 PM, Alvaro Herrera [EMAIL PROTECTED] wrote:
Jaime Casanova escribió:
it doesn't compile on current head on mingw 5.1 and msys 1.0.10; of
course, it doesn't compile on 8.2 neither in order to Alvaro's contact
to test it
I think this patch should fix it. I think
On Sun, Dec 16, 2007 at 10:31:59AM +, Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
Interesting. Maybe forever is going a bit too far, but retrying for n
seconds or so.
I think looping
On Sat, Dec 15, 2007 at 10:31:38PM -0500, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
Interesting. Maybe forever is going a bit too far, but retrying for n
seconds or so.
I think looping forever is the right thing. Having a fixed
Magnus Hagander [EMAIL PROTECTED] writes:
If your software is locking a file for that long, that software is more
than just broken, it's horribly broken. Having a workaround against
something that might happen once or twice because of a bug in the other
software is one thing, but if it's
On Wed, Dec 19, 2007 at 01:05:00PM +, Gregory Stark wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
If your software is locking a file for that long, that software is more
than just broken, it's horribly broken. Having a workaround against
something that might happen once or twice
On Wed, Dec 19, 2007 at 11:23:35AM -0300, Alvaro Herrera wrote:
Magnus Hagander wrote:
On Sat, Dec 15, 2007 at 10:31:38PM -0500, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
Interesting. Maybe forever is going a bit too far, but
Magnus Hagander wrote:
On Sat, Dec 15, 2007 at 10:31:38PM -0500, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
Interesting. Maybe forever is going a bit too far, but retrying for n
seconds or so.
I think looping forever is the
Yeah, I think it would be useful to log one message if after (say) 5
seconds we still haven't been able to open the file.
Either that, or on the first run.
Imho 1-5s is better, so that would be after the 10-50th try.
loop. It's supposed to loop 300 times.
Yes.
(Are we OK with the
Zeugswetter Andreas ADI SD wrote:
Yes 0.1 s is imho good. Btw. m$ is talking about milliseconds
(http://support.microsoft.com/kb/316609)
We have seen cases in the past where these locks last quite a long time.
That 30s total timeout in rename and unlink was not chosen arbitrarily -
On Wed, Dec 19, 2007 at 04:20:23PM +0100, Zeugswetter Andreas ADI SD wrote:
Yeah, I think it would be useful to log one message if after (say) 5
seconds we still haven't been able to open the file.
Either that, or on the first run.
Imho 1-5s is better, so that would be after the
On Wed, Dec 19, 2007 at 04:44:12PM +0100, Magnus Hagander wrote:
On Wed, Dec 19, 2007 at 04:20:23PM +0100, Zeugswetter Andreas ADI SD wrote:
Yeah, I think it would be useful to log one message if after (say) 5
seconds we still haven't been able to open the file.
Either that, or
Zeugswetter Andreas ADI SD wrote:
I think not. 0.1 seconds is better. We don't want to delay a full
second if it's just a transient thing.
Yes 0.1 s is imho good. Btw. m$ is talking about milliseconds
(http://support.microsoft.com/kb/316609)
Hm, the article only mentions
Magnus Hagander [EMAIL PROTECTED] writes:
Updated version attached. Comments on the wording of the messages are also
welcome ;-)
Well, since you asked ;-) ... I don't particularly like this.
1. Doesn't distinguish SHARING_VIOLATION from LOCK_VIOLATION.
We might want to know that.
2. Do we
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
Interesting. Maybe forever is going a bit too far, but retrying for n
seconds or so.
I think looping forever is the right thing. Having a fixed timeout just means
Postgres
Alvaro Herrera wrote:
Magnus Hagander wrote:
On Thu, Dec 13, 2007 at 09:55:33AM -0300, Alvaro Herrera wrote:
Many of these are nonsensical -- we know this is not a device, nor
network access. Still there is more than one possibility, and I don't
know which ones should be really acceptable in
Magnus Hagander wrote:
Alvaro Herrera wrote:
Magnus Hagander wrote:
On Thu, Dec 13, 2007 at 09:55:33AM -0300, Alvaro Herrera wrote:
Many of these are nonsensical -- we know this is not a device, nor
network access. Still there is more than one possibility, and I don't
know
Andrew Dunstan [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
Alvaro Herrera wrote:
Magnus Hagander wrote:
Note that their behavior on finding SHARING_VIOLATION or LOCK_VIOLATION
is to retry forever until the error goes away, on the theory that the
antivirus/backup software will
Gregory Stark [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
Interesting. Maybe forever is going a bit too far, but retrying for n
seconds or so.
I think looping forever is the right thing. Having a fixed timeout just means
Postgres will break sometimes instead of all the
On Thu, Dec 13, 2007 at 09:55:33AM -0300, Alvaro Herrera wrote:
Alvaro Herrera wrote:
So _anything_ could be EINVAL. Including the several cases that
_dosmaperr treat as EACCES. So I'm afraid that for this experiment to
be successful, we would have to remove not only the EINVAL cases
Magnus Hagander wrote:
On Thu, Dec 13, 2007 at 09:55:33AM -0300, Alvaro Herrera wrote:
Many of these are nonsensical -- we know this is not a device, nor
network access. Still there is more than one possibility, and I don't
know which ones should be really acceptable in this context or
Alvaro Herrera wrote:
So _anything_ could be EINVAL. Including the several cases that
_dosmaperr treat as EACCES. So I'm afraid that for this experiment to
be successful, we would have to remove not only the EINVAL cases from
doserrors[], but also any other code that appears more than once
On Thu, Nov 29, 2007 at 05:48:23PM -0500, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, since EINVAL is the default result from _dosmaperr, and none of
the cases it represents are expected, why don't we just remove all of
the explicit mappings to EINVAL
On Wed, Nov 28, 2007 at 05:20:46PM +0100, Magnus Hagander wrote:
On Wed, Nov 28, 2007 at 12:24:26PM -0300, Alvaro Herrera wrote:
Martijn van Oosterhout wrote:
On Wed, Nov 28, 2007 at 11:57:35AM -0300, Alvaro Herrera wrote:
Can we do something like this to report the Win32 error code so
On Thu, Nov 29, 2007 at 09:09:47AM -0300, Alvaro Herrera wrote:
Magnus Hagander wrote:
On Wed, Nov 28, 2007 at 05:20:46PM +0100, Magnus Hagander wrote:
On Wed, Nov 28, 2007 at 12:24:26PM -0300, Alvaro Herrera wrote:
Martijn van Oosterhout wrote:
On Wed, Nov 28, 2007 at 11:57:35AM
Magnus Hagander wrote:
On Wed, Nov 28, 2007 at 05:20:46PM +0100, Magnus Hagander wrote:
On Wed, Nov 28, 2007 at 12:24:26PM -0300, Alvaro Herrera wrote:
Martijn van Oosterhout wrote:
On Wed, Nov 28, 2007 at 11:57:35AM -0300, Alvaro Herrera wrote:
Can we do something like this to
On Thu, Nov 29, 2007 at 09:43:30AM -0300, Alvaro Herrera wrote:
Magnus Hagander wrote:
On Thu, Nov 29, 2007 at 09:09:47AM -0300, Alvaro Herrera wrote:
Magnus Hagander wrote:
On Wed, Nov 28, 2007 at 05:20:46PM +0100, Magnus Hagander wrote:
On Wed, Nov 28, 2007 at 12:24:26PM -0300,
Magnus Hagander wrote:
On Thu, Nov 29, 2007 at 09:09:47AM -0300, Alvaro Herrera wrote:
Magnus Hagander wrote:
On Wed, Nov 28, 2007 at 05:20:46PM +0100, Magnus Hagander wrote:
On Wed, Nov 28, 2007 at 12:24:26PM -0300, Alvaro Herrera wrote:
Martijn van Oosterhout wrote:
On Wed,
Magnus Hagander wrote:
On Thu, Nov 29, 2007 at 09:43:30AM -0300, Alvaro Herrera wrote:
Magnus Hagander wrote:
Maybe. I'm concerned we might end up logging a whole lot more, for cases
where it's not an actual error. For example, a file that doesn't exist
doesn't necessarily mean it's
Alvaro Herrera [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
Maybe. I'm concerned we might end up logging a whole lot more, for cases
where it's not an actual error.
I'm very concerned about that too, and think that DEBUG5 is just fine.
Hmm, I just noticed a bug in those fprintf calls --
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
Maybe. I'm concerned we might end up logging a whole lot more, for cases
where it's not an actual error.
I'm very concerned about that too, and think that DEBUG5 is just fine.
Well, the analysis was already
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm very concerned about that too, and think that DEBUG5 is just fine.
Well, the analysis was already done which says this shouldn't be a problem.
That analysis is full of holes --- FileRead and FileWrite for starters.
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm very concerned about that too, and think that DEBUG5 is just fine.
Well, the analysis was already done which says this shouldn't be a problem.
That analysis is full of holes --- FileRead and FileWrite for
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
That analysis is full of holes --- FileRead and FileWrite for starters.
I already did. The case where they retry do not call _dosmaperr.
What's retry got to do with it? What's displeasing me is the idea of
LOG messages showing up
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
That analysis is full of holes --- FileRead and FileWrite for starters.
I already did. The case where they retry do not call _dosmaperr.
What's retry got to do with it? What's displeasing me is the idea of
LOG
Alvaro Herrera [EMAIL PROTECTED] writes:
I think a reasonable compromise is to turn the ereport() in _dosmaperr
to DEBUG1 instead. That way it won't clutter any log by default, and in
the cases where we're actually interested in tracking the problematic
situation, we don't need to get huge
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm still not convinced what you think the problematic situation is.
I believe Alvaros point is that several different GetLastError codes map
to the same errno code, making it impossible to see the difference
between those errors.
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I think a reasonable compromise is to turn the ereport() in _dosmaperr
to DEBUG1 instead. That way it won't clutter any log by default, and in
the cases where we're actually interested in tracking the problematic
situation, we don't
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm still not convinced what you think the problematic situation is.
I believe Alvaros point is that several different GetLastError codes map
to the same errno code, making it impossible to see the difference
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
(2) Do we have any live cases where we must know this?
Yes. This thread shows the problem:
http://archives.postgresql.org/pgsql-es-ayuda/2007-11/msg00354.php
Basically he is getting this error:
2007-11-16 14:54:16 ERROR: could not
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
(2) Do we have any live cases where we must know this?
Yes. This thread shows the problem:
http://archives.postgresql.org/pgsql-es-ayuda/2007-11/msg00354.php
Basically he is getting this error:
2007-11-16
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
(2) Do we have any live cases where we must know this?
Yes. This thread shows the problem:
http://archives.postgresql.org/pgsql-es-ayuda/2007-11/msg00354.php
Basically he is getting this error:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, since EINVAL is the default result from _dosmaperr, and none of
the cases it represents are expected, why don't we just remove all of
the explicit mappings to EINVAL from doserrors[]?
Well, the problematic routine is not already
Hi,
We've seen several cases of people (running 8.1 or 8.2) that see
messages like this:
2007-11-26 11:41:59 ERROR: could not open relation 1663/352369/353685: Invalid
argument
The platform is Win32.
The problem is that pgwin32_open reduces any error code from
GetLastError that's not
On Wed, Nov 28, 2007 at 11:57:35AM -0300, Alvaro Herrera wrote:
Can we do something like this to report the Win32 error code so that the
user has a higher chance of figuring out what's going on?
The Windows API provides a way to get the error message associated
with the code. It seems it would
Martijn van Oosterhout wrote:
On Wed, Nov 28, 2007 at 11:57:35AM -0300, Alvaro Herrera wrote:
Can we do something like this to report the Win32 error code so that the
user has a higher chance of figuring out what's going on?
The Windows API provides a way to get the error message
On Wed, Nov 28, 2007 at 12:24:26PM -0300, Alvaro Herrera wrote:
Martijn van Oosterhout wrote:
On Wed, Nov 28, 2007 at 11:57:35AM -0300, Alvaro Herrera wrote:
Can we do something like this to report the Win32 error code so that the
user has a higher chance of figuring out what's going on?
67 matches
Mail list logo
