On Mon, Sep 27, 2010 at 14:34, Dave Page dp...@pgadmin.org wrote:
On Thu, Sep 9, 2010 at 9:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
It's hard to say what the safest option is, I think. There seem to be
basically three proposals on the table:
1.
On Mon, Sep 27, 2010 at 14:34, Dave Page dp...@pgadmin.org wrote:
On Thu, Sep 9, 2010 at 9:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
It's hard to say what the safest option is, I think. There seem to be
basically three proposals on the table:
1.
On Wed, Sep 29, 2010 at 2:45 PM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Sep 27, 2010 at 14:34, Dave Page dp...@pgadmin.org wrote:
On Thu, Sep 9, 2010 at 9:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
It's hard to say what the safest option is,
On Wed, Sep 29, 2010 at 15:54, Dave Page dp...@pgadmin.org wrote:
On Wed, Sep 29, 2010 at 2:45 PM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Sep 27, 2010 at 14:34, Dave Page dp...@pgadmin.org wrote:
On Thu, Sep 9, 2010 at 9:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas
On Thu, Sep 9, 2010 at 9:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
It's hard to say what the safest option is, I think. There seem to be
basically three proposals on the table:
1. Back-port the dead-man switch, and ignore exit 128.
2. Don't
On Wed, Sep 15, 2010 at 19:25, Robert Haas robertmh...@gmail.com wrote:
On Wed, Sep 15, 2010 at 4:03 AM, Dave Page dp...@pgadmin.org wrote:
Therefore I cannot give you specific areas where this will happen. Of
course when systems are low on resources or they are completely
depleted (100% CPU)
Dave Page wrote:
On Fri, Sep 10, 2010 at 1:45 PM, Bruce Momjian br...@momjian.us wrote:
I am not sure how clear it is on Win32 that 128 is a special return
code.
I asked Microsoft platform support (roughly) that question. Here's the
response:
I assume we are going to summarize this in
Magnus Hagander mag...@hagander.net writes:
So, it's been tested by at leasdt one EDB customer with success.
Do we want to sneak this in before we release 9.0.0?
I think we had consensus on applying the simple fix as far back as we
have the deadman switch code. If you can get it done in the
Bruce Momjian br...@momjian.us writes:
Can we assume all the mutexes will be cleaned up from a 128-exit?
In the deadman-switch case I think we're safe enough. I'm not convinced
at the moment that ignoring the error would be safe without that.
regards, tom lane
--
Sent
On Thu, Sep 16, 2010 at 19:30, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
So, it's been tested by at leasdt one EDB customer with success.
Do we want to sneak this in before we release 9.0.0?
I think we had consensus on applying the simple fix as far back
On 09/16/2010 04:37 PM, Magnus Hagander wrote:
On Thu, Sep 16, 2010 at 19:30, Tom Lanet...@sss.pgh.pa.us wrote:
Magnus Hagandermag...@hagander.net writes:
So, it's been tested by at leasdt one EDB customer with success.
Do we want to sneak this in before we release 9.0.0?
I think we had
On 09/16/2010 05:29 PM, Andrew Dunstan wrote:
On 09/16/2010 04:37 PM, Magnus Hagander wrote:
On Thu, Sep 16, 2010 at 19:30, Tom Lanet...@sss.pgh.pa.us wrote:
Magnus Hagandermag...@hagander.net writes:
So, it's been tested by at leasdt one EDB customer with success.
Do we want to sneak
Andrew Dunstan and...@dunslane.net writes:
Looks like we're green on 9.0 for both MinGW and MSVC.
Would you kick brown_bat too so we can check the cygwin case?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On 09/16/2010 08:50 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
Looks like we're green on 9.0 for both MinGW and MSVC.
Would you kick brown_bat too so we can check the cygwin case?
Done. Looks fine.
cheers
andrew
--
Sent via pgsql-hackers mailing list
On Fri, Sep 10, 2010 at 1:45 PM, Bruce Momjian br...@momjian.us wrote:
I am not sure how clear it is on Win32 that 128 is a special return
code.
I asked Microsoft platform support (roughly) that question. Here's the response:
=
From NTSTATUS.H
//
// The success status codes 128 - 191 are
On Wed, Sep 15, 2010 at 4:03 AM, Dave Page dp...@pgadmin.org wrote:
Therefore I cannot give you specific areas where this will happen. Of
course when systems are low on resources or they are completely
depleted (100% CPU) things will stop working
Of course. As we all know, degrading
On Thu, Sep 9, 2010 at 20:23, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, Sep 9, 2010 at 19:48, Tom Lane t...@sss.pgh.pa.us wrote:
On balance I think I'd suggest an #ifdef WIN32 in CleanupBackend that
made it accept 128 as a normal exit case.
Seems
On Fri, Sep 10, 2010 at 03:12, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Thu, Sep 9, 2010 at 3:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
We certainly now have MANY documented field complaints at least of the
exit-128-on-Windows
Magnus Hagander wrote:
I think we have clear enough evidence that 128 on Win32 means
no-such-child and we can be sure the child never got started on that
platform.
We have evidence that 128 occurs in this case. I don't think we have
evidence that there is no other case when this can
On Tue, Aug 24, 2010 at 15:58, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Yeah, that seems very plausible, although exactly how to verify I don't
know.
And here is confirmation from the Microsoft web site:
In some instances, calling
Magnus Hagander mag...@hagander.net writes:
On Tue, Aug 24, 2010 at 15:58, Tom Lane t...@sss.pgh.pa.us wrote:
Given the existence of the deadman switch mechanism (which I hadn't
remembered when this thread started), I'm coming around to the idea that
we could just treat exit(128) as nonfatal
On Thu, Sep 9, 2010 at 19:48, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Aug 24, 2010 at 15:58, Tom Lane t...@sss.pgh.pa.us wrote:
Given the existence of the deadman switch mechanism (which I hadn't
remembered when this thread started), I'm coming
Magnus Hagander mag...@hagander.net writes:
On Thu, Sep 9, 2010 at 19:48, Tom Lane t...@sss.pgh.pa.us wrote:
On balance I think I'd suggest an #ifdef WIN32 in CleanupBackend that
made it accept 128 as a normal exit case.
Seems reasonable. I'll whack it around for that - see attached.
Hm,
On Thu, Sep 9, 2010 at 2:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We're not so worried about this case that we'd want to backport the
deadman switch into 8.3 or 8.2 to have a fix there, are we?
I think we should consider backporting the deadman switch to 8.3 and 8.2.
--
Robert Haas
Robert Haas robertmh...@gmail.com writes:
On Thu, Sep 9, 2010 at 2:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We're not so worried about this case that we'd want to backport the
deadman switch into 8.3 or 8.2 to have a fix there, are we?
I think we should consider backporting the deadman
On Thu, Sep 9, 2010 at 21:00, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Sep 9, 2010 at 2:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We're not so worried about this case that we'd want to backport the
deadman switch into 8.3 or 8.2 to have a fix there,
Magnus Hagander mag...@hagander.net writes:
On Thu, Sep 9, 2010 at 21:00, Tom Lane t...@sss.pgh.pa.us wrote:
The thrust of my question was more along the lines of whether we should
look for a different solution to the current problem, so that we would
have something that could be back-ported
On Thu, Sep 9, 2010 at 3:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Sep 9, 2010 at 2:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We're not so worried about this case that we'd want to backport the
deadman switch into 8.3 or 8.2 to have a fix
Robert Haas robertmh...@gmail.com writes:
We certainly now have MANY documented field complaints at least of the
exit-128-on-Windows problem, if not the more general
backend-exits-without-going-through-the-normal-cleanup-path problem.
Right, which is why I still don't care to risk back-porting
On Thu, Sep 9, 2010 at 3:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
We certainly now have MANY documented field complaints at least of the
exit-128-on-Windows problem, if not the more general
backend-exits-without-going-through-the-normal-cleanup-path
Robert Haas robertmh...@gmail.com writes:
It's hard to say what the safest option is, I think. There seem to be
basically three proposals on the table:
1. Back-port the dead-man switch, and ignore exit 128.
2. Don't back-port the dead-man switch, but ignore exit 128 anyway.
3. Revert to
On Thu, Sep 9, 2010 at 22:09, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
It's hard to say what the safest option is, I think. There seem to be
basically three proposals on the table:
1. Back-port the dead-man switch, and ignore exit 128.
2. Don't back-port
Robert Haas wrote:
On Thu, Sep 9, 2010 at 3:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
We certainly now have MANY documented field complaints at least of the
exit-128-on-Windows problem, if not the more general
On Wed, Sep 1, 2010 at 3:49 PM, Cristian Bittel cbit...@gmail.com wrote:
Maybe the issue, for the momtent, could be avoided modifying the shared heap
for sessions on Windows. But I don't really have idea how much to increase
or decrease the values. Try and error? But, inside the opened Windows
Maybe the issue, for the momtent, could be avoided modifying the shared heap
for sessions on Windows. But I don't really have idea how much to increase
or decrease the values. Try and error? But, inside the opened Windows
sessions nothing alerts of a heap exaust so could be unpredictable how much
On Sun, Aug 29, 2010 at 12:05 PM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Aug 26, 2010 at 22:59, Cristian Bittel cbit...@gmail.com wrote:
I still believe this exit code 128 is related to pgAdmin opened during the
clossing session on Remote Desktop. I have a Windows user login wich is
On Tue, Aug 31, 2010 at 3:40 PM, Cristian Bittel cbit...@gmail.com wrote:
To Dave's question, this behavior occurs on all Windows Server interactive
sessions, no matter if Administrators or underpriviledge users, but is
related to closing Windows interactive session while pgAdmin window is
Dave Page wrote:
On Tue, Aug 31, 2010 at 3:40 PM, Cristian Bittel cbit...@gmail.com wrote:
To Dave's question, this behavior occurs on all Windows Server interactive
sessions, no matter if Administrators or underpriviledge users, but is
related to closing Windows interactive session while
On Tue, Aug 31, 2010 at 4:27 PM, Bruce Momjian br...@momjian.us wrote:
Dave Page wrote:
On Tue, Aug 31, 2010 at 3:40 PM, Cristian Bittel cbit...@gmail.com wrote:
To Dave's question, this behavior occurs on all Windows Server interactive
sessions, no matter if Administrators or
Dave Page wrote:
On Tue, Aug 31, 2010 at 4:27 PM, Bruce Momjian br...@momjian.us wrote:
Dave Page wrote:
On Tue, Aug 31, 2010 at 3:40 PM, Cristian Bittel cbit...@gmail.com wrote:
To Dave's question, this behavior occurs on all Windows Server
interactive
sessions, no matter if
I am the remote support guy for a web developed application
(Apache+PHP+Pg. Postgres is isolated on a server, Apache runs on another
server), and installed at our client, our client is the Administrator user
on Windows Server, I just have a limited privileges Windows user for
monitoring. I have my
On Tue, Aug 31, 2010 at 4:35 PM, Bruce Momjian br...@momjian.us wrote:
Dave Page wrote:
On Tue, Aug 31, 2010 at 4:27 PM, Bruce Momjian br...@momjian.us wrote:
We have already found that exceeding desktop heap might cause a
CreateProcess to return success but later fail with a return code of
Dave Page wrote:
On Tue, Aug 31, 2010 at 4:35 PM, Bruce Momjian br...@momjian.us wrote:
Dave Page wrote:
On Tue, Aug 31, 2010 at 4:27 PM, Bruce Momjian br...@momjian.us wrote:
We have already found that exceeding desktop heap might cause a
CreateProcess to return success but later fail
On Thu, Aug 26, 2010 at 22:59, Cristian Bittel cbit...@gmail.com wrote:
I still believe this exit code 128 is related to pgAdmin opened during the
clossing session on Remote Desktop. I have a Windows user login wich is not
administrator just no privileged user, it cannot start/stop services,
On Tue, Aug 24, 2010 at 9:58 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Yeah, that seems very plausible, although exactly how to verify I don't
know.
And here is confirmation from the Microsoft web site:
In some instances,
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 24, 2010 at 9:58 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Given the existence of the deadman switch mechanism (which I hadn't
remembered when this thread started), I'm coming around to the idea that
we could just treat exit(128) as nonfatal
I still believe this exit code 128 is related to pgAdmin opened during the
clossing session on Remote Desktop. I have a Windows user login wich is not
administrator just no privileged user, it cannot start/stop services, just
monitoring. With pgAdmin window opened inside my disconected session, as
Robert Haas wrote:
[moving to -hackers]
On Thu, Aug 19, 2010 at 9:43 PM, Robert Haas robertmh...@gmail.com wrote:
I suspect this is the same problem as bug #4897, and probably also the
same problem as this:
http://archives.postgresql.org/pgsql-bugs/2009-08/msg00114.php
and maybe also
On Tue, Aug 24, 2010 at 8:57 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
[moving to -hackers]
On Thu, Aug 19, 2010 at 9:43 PM, Robert Haas robertmh...@gmail.com wrote:
I suspect this is the same problem as bug #4897, and probably also the
same problem as this:
Robert Haas wrote:
This isn't really a fix for the bug in the sense that the nicest
thing of all would be to prevent the child from exiting abnormally in
the first place. ?But it's far from clear that we can control that.
This URL has some interesting details on our problem:
? ? ?
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Yeah, that seems very plausible, although exactly how to verify I don't know.
And here is confirmation from the Microsoft web site:
In some instances, calling GetExitCode() against the failed process
indicates the
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Yeah, that seems very plausible, although exactly how to verify I don't
know.
And here is confirmation from the Microsoft web site:
In some instances, calling GetExitCode() against the failed
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Yeah, that seems very plausible, although exactly how to verify I don't
know.
And here is confirmation from the Microsoft web site:
In some instances, calling GetExitCode() against the failed
On Tue, Aug 24, 2010 at 15:58, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Yeah, that seems very plausible, although exactly how to verify I don't
know.
And here is confirmation from the Microsoft web site:
In some instances, calling
Magnus Hagander wrote:
On Tue, Aug 24, 2010 at 15:58, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Yeah, that seems very plausible, although exactly how to verify I don't
know.
And here is confirmation from the Microsoft web site:
?
On Tue, Aug 24, 2010 at 21:14, Bruce Momjian br...@momjian.us wrote:
Magnus Hagander wrote:
On Tue, Aug 24, 2010 at 15:58, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Yeah, that seems very plausible, although exactly how to verify I don't
On Tue, Aug 24, 2010 at 3:10 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Aug 24, 2010 at 15:58, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Yeah, that seems very plausible, although exactly how to verify I don't
know.
And here is
On Tue, Aug 24, 2010 at 21:39, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 24, 2010 at 3:10 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Aug 24, 2010 at 15:58, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Yeah, that seems very
On Tue, Aug 24, 2010 at 9:58 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Yeah, that seems very plausible, although exactly how to verify I don't
know.
And here is confirmation from the Microsoft web site:
In some instances,
Robert Haas robertmh...@gmail.com writes:
There is some amount of user code (I'm not sure preceisely how much)
that runs after shared memory is mapped and before the deadman switch
is engaged.
Er ... what would you define as user code?
The deadman switch is engaged at the point where we
On Tue, Aug 24, 2010 at 5:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
There is some amount of user code (I'm not sure preceisely how much)
that runs after shared memory is mapped and before the deadman switch
is engaged.
Er ... what would you define as
On Tue, Aug 24, 2010 at 08:17:15PM -0400, Robert Haas wrote:
On Tue, Aug 24, 2010 at 5:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
There is some amount of user code (I'm not sure preceisely how
much) that runs after shared memory is mapped and before
[moving to -hackers]
On Thu, Aug 19, 2010 at 9:43 PM, Robert Haas robertmh...@gmail.com wrote:
I suspect this is the same problem as bug #4897, and probably also the
same problem as this:
http://archives.postgresql.org/pgsql-bugs/2009-08/msg00114.php
and maybe also this and this:
Robert Haas robertmh...@gmail.com writes:
After some discussion with Magnus, I think what is going on here is
that the postmaster kicks off a new child process, which terminates
before it actually starts running our code, either in OS-supplied code
or some sort of filter like anti-spam or
On Mon, Aug 23, 2010 at 17:09, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
After some discussion with Magnus, I think what is going on here is
that the postmaster kicks off a new child process, which terminates
before it actually starts running our code, either
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 23, 2010 at 17:09, Tom Lane t...@sss.pgh.pa.us wrote:
I would be inclined to write this off as Windows randomness that's
unfixable on our end. We could recommend that people take a closer
look at what AV software they have installed and
On Mon, Aug 23, 2010 at 11:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 23, 2010 at 17:09, Tom Lane t...@sss.pgh.pa.us wrote:
I would be inclined to write this off as Windows randomness that's
unfixable on our end. We could recommend that
From the users point of view, this could be a Windows or AV issue, but just
stops Postgres service, does not affect or interfire on Windows stability or
AV stability, instead it affect your product. So if you can improve the
stability of the service (and data integrity at the most) it could be a
68 matches
Mail list logo
