On Wed, Sep 29, 2010 at 15:54, Dave Page wrote:
> On Wed, Sep 29, 2010 at 2:45 PM, Magnus Hagander wrote:
>> On Mon, Sep 27, 2010 at 14:34, Dave Page wrote:
>>> On Thu, Sep 9, 2010 at 9:09 PM, Tom Lane wrote:
Robert Haas writes:
> It's hard to say what the safest option is, I think.
On Wed, Sep 29, 2010 at 2:45 PM, Magnus Hagander wrote:
> On Mon, Sep 27, 2010 at 14:34, Dave Page wrote:
>> On Thu, Sep 9, 2010 at 9:09 PM, Tom Lane wrote:
>>> Robert Haas writes:
It's hard to say what the safest option is, I think. There seem to be
basically three proposals on the
On Mon, Sep 27, 2010 at 14:34, Dave Page wrote:
> On Thu, Sep 9, 2010 at 9:09 PM, Tom Lane wrote:
>> Robert Haas 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
On Mon, Sep 27, 2010 at 14:34, Dave Page wrote:
> On Thu, Sep 9, 2010 at 9:09 PM, Tom Lane wrote:
>> Robert Haas 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
On Thu, Sep 9, 2010 at 9:09 PM, Tom Lane wrote:
> Robert Haas 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 ign
On 09/16/2010 08:50 PM, Tom Lane wrote:
Andrew Dunstan 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 (pgsql-hackers@postgresql.org)
To ma
Andrew Dunstan 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 your subscription:
ht
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 Lane wrote:
Magnus Hagander 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 thi
On 09/16/2010 04:37 PM, Magnus Hagander wrote:
On Thu, Sep 16, 2010 at 19:30, Tom Lane wrote:
Magnus Hagander 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
On Thu, Sep 16, 2010 at 19:30, Tom Lane wrote:
> Magnus Hagander 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 switc
Bruce Momjian 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 via pgsql-hacke
Magnus Hagander 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 next
few hours, go
Dave Page wrote:
> On Fri, Sep 10, 2010 at 1:45 PM, Bruce Momjian 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 a C co
On Wed, Sep 15, 2010 at 19:25, Robert Haas wrote:
> On Wed, Sep 15, 2010 at 4:03 AM, Dave Page 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
On Wed, Sep 15, 2010 at 4:03 AM, Dave Page 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 gracefully under load i
On Fri, Sep 10, 2010 at 1:45 PM, Bruce Momjian 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 reserved for
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
On Fri, Sep 10, 2010 at 03:12, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Thu, Sep 9, 2010 at 3:28 PM, Tom Lane wrote:
>> > Robert Haas writes:
>> >> We certainly now have MANY documented field complaints at least of the
>> >> exit-128-on-Windows problem, if not the more general
>> >> backe
On Thu, Sep 9, 2010 at 20:23, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, Sep 9, 2010 at 19:48, Tom Lane 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
Robert Haas wrote:
> On Thu, Sep 9, 2010 at 3:28 PM, Tom Lane wrote:
> > Robert Haas 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 probl
On Thu, Sep 9, 2010 at 22:09, Tom Lane wrote:
> Robert Haas 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 ignor
Robert Haas 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 Magnus's original so
On Thu, Sep 9, 2010 at 3:28 PM, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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 a fix for
the latt
On Thu, Sep 9, 2010 at 3:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Sep 9, 2010 at 2:23 PM, Tom Lane 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 backpor
Magnus Hagander writes:
> On Thu, Sep 9, 2010 at 21:00, Tom Lane 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 into 8.2 and 8.3. Personally
>>
On Thu, Sep 9, 2010 at 21:00, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Sep 9, 2010 at 2:23 PM, Tom Lane 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 backporti
Robert Haas writes:
> On Thu, Sep 9, 2010 at 2:23 PM, Tom Lane 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.
[ raised eyebro
On Thu, Sep 9, 2010 at 2:23 PM, Tom Lane 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
EnterpriseDB: http://www.e
Magnus Hagander writes:
> On Thu, Sep 9, 2010 at 19:48, Tom Lane 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, still doesn't log, which I think
On Thu, Sep 9, 2010 at 19:48, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Aug 24, 2010 at 15:58, Tom Lane 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 e
Magnus Hagander writes:
> On Tue, Aug 24, 2010 at 15:58, Tom Lane 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 Windows. If for some
>> reas
On Tue, Aug 24, 2010 at 15:58, Tom Lane wrote:
> Bruce Momjian 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() agains
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
t
On Wed, Sep 1, 2010 at 3:49 PM, Cristian Bittel 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
> sessions noth
Dave Page wrote:
> On Tue, Aug 31, 2010 at 4:35 PM, Bruce Momjian wrote:
> > Dave Page wrote:
> >> On Tue, Aug 31, 2010 at 4:27 PM, Bruce Momjian wrote:
> >> > We have already found that exceeding desktop heap might cause a
> >> > CreateProcess to return success but later fail with a return code
On Tue, Aug 31, 2010 at 4:35 PM, Bruce Momjian wrote:
> Dave Page wrote:
>> On Tue, Aug 31, 2010 at 4:27 PM, Bruce Momjian wrote:
>> > We have already found that exceeding desktop heap might cause a
>> > CreateProcess to return success but later fail with a return code of
>> > 128, which causes a
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 m
Dave Page wrote:
> On Tue, Aug 31, 2010 at 4:27 PM, Bruce Momjian wrote:
> > Dave Page wrote:
> >> On Tue, Aug 31, 2010 at 3:40 PM, Cristian Bittel wrote:
> >> > To Dave's question, this behavior occurs on all Windows Server
> >> > interactive
> >> > sessions, no matter if Administrators or unde
On Tue, Aug 31, 2010 at 4:27 PM, Bruce Momjian wrote:
> Dave Page wrote:
>> On Tue, Aug 31, 2010 at 3:40 PM, Cristian Bittel wrote:
>> > To Dave's question, this behavior occurs on all Windows Server interactive
>> > sessions, no matter if Administrators or underpriviledge users, but is
>> > rela
Dave Page wrote:
> On Tue, Aug 31, 2010 at 3:40 PM, Cristian Bittel 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 wind
On Tue, Aug 31, 2010 at 3:40 PM, Cristian Bittel 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
> opened and connec
On Sun, Aug 29, 2010 at 12:05 PM, Magnus Hagander wrote:
> On Thu, Aug 26, 2010 at 22:59, Cristian Bittel 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
On Thu, Aug 26, 2010 at 22:59, Cristian Bittel 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, just
> monitori
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, a
Robert Haas writes:
> On Tue, Aug 24, 2010 at 9:58 AM, Tom Lane 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 Windows. If for some
>> reason
On Tue, Aug 24, 2010 at 9:58 AM, Tom Lane wrote:
> Bruce Momjian 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() agai
On Tue, Aug 24, 2010 at 08:17:15PM -0400, Robert Haas wrote:
> On Tue, Aug 24, 2010 at 5:11 PM, Tom Lane wrote:
> > Robert Haas 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 enga
On Tue, Aug 24, 2010 at 5:11 PM, Tom Lane wrote:
> Robert Haas 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"?
Our code, as opp
Robert Haas 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 create a PGPROC.
Befor
On Tue, Aug 24, 2010 at 9:58 AM, Tom Lane wrote:
> Bruce Momjian 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() agai
On Tue, Aug 24, 2010 at 21:39, Robert Haas wrote:
> On Tue, Aug 24, 2010 at 3:10 PM, Magnus Hagander wrote:
>> On Tue, Aug 24, 2010 at 15:58, Tom Lane wrote:
>>> Bruce Momjian writes:
Robert Haas wrote:
> Yeah, that seems very plausible, although exactly how to verify I don't
> kn
On Tue, Aug 24, 2010 at 3:10 PM, Magnus Hagander wrote:
> On Tue, Aug 24, 2010 at 15:58, Tom Lane wrote:
>> Bruce Momjian 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
On Tue, Aug 24, 2010 at 21:14, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On Tue, Aug 24, 2010 at 15:58, Tom Lane wrote:
>> > Bruce Momjian writes:
>> >> Robert Haas wrote:
>> >>> Yeah, that seems very plausible, although exactly how to verify I don't
>> >>> know.
>> >
>> >> And here is c
Magnus Hagander wrote:
> On Tue, Aug 24, 2010 at 15:58, Tom Lane wrote:
> > Bruce Momjian 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 som
On Tue, Aug 24, 2010 at 15:58, Tom Lane wrote:
> Bruce Momjian 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() agains
Tom Lane wrote:
> Bruce Momjian 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
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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 following
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
On Tue, Aug 24, 2010 at 8:57 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> [moving to -hackers]
>>
>> On Thu, Aug 19, 2010 at 9:43 PM, Robert Haas wrote:
>> > I suspect this is the same problem as bug #4897, and probably also the
>> > same problem as this:
>> > http://archives.postgresql.org/p
Robert Haas wrote:
> [moving to -hackers]
>
> On Thu, Aug 19, 2010 at 9:43 PM, Robert Haas 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
>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
b
On Mon, Aug 23, 2010 at 11:37 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 23, 2010 at 17:09, Tom Lane 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 softwar
Magnus Hagander writes:
> On Mon, Aug 23, 2010 at 17:09, Tom Lane 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 maybe try some other
>> one.
>
On Mon, Aug 23, 2010 at 17:09, Tom Lane wrote:
> Robert Haas 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 s
Robert Haas 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 anti-virus software.
[moving to -hackers]
On Thu, Aug 19, 2010 at 9:43 PM, Robert Haas 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:
> http://archives.postgresql
68 matches
Mail list logo
