From my side, i have no choice to get the stack trace from production
servers where i found the issue. I have another several servers with
almost the same config to development purposes and no crashes there. I
don't have any code into the database, there is no compiled functions,
just sql queries from php code, using persistant connections
pg_pconnect().
All bugs sseams to be the same issue, took some time to relate the
crashes with exit code 128 to the terminal session ends, sometimes
there is more than one session started.
Is just a world wide issue or is something that affects to a
non-USenglish version of Windows 2003 Standard x64 Servers?
mine are in spanish lang, other report is in french lang, other report
came from british. And seems to be independant from Postgres version,
i use 8.3.9 and there is another report with 8.4.1. There is a new
version of PgAdmin, maybe should i replace the original provided with
postgres.
all appreciate your big effort,
Cristian.
2010/8/19, Robert Haas <robertmhaas@gmail.com>:
> On Sat, Feb 6, 2010 at 9:09 PM, Chris Travers <chris@metatrontech.com>
> wrote:
>> On Sat, Feb 6, 2010 at 2:36 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> That's really odd. Nothing pgAdmin does should be able to crash the
>>> PostgreSQL server, I would think. Have you got any custom code loaded
>>> into PostgreSQL? Or non-custom, but buggy?
>>>
>>> I'm guessing the problem only occurs if PGadmin is actually connected
>>> to the PostgreSQL server, but perhaps you could verify that. If so, I
>>> would see if you can get a stack backtrace of the backend to which
>>> PGadmin is connected.
>>
>> It wouldn't surprise me if this were a Windows bug (Terminal Services
>> may have improved since I was supporting it but it used to be quite
>> common that it would cause weird behavior in applications).... I
>> personally think the stack trace is likely to be the best way to test
>> where the problem is.
>
> 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.org/pgsql-bugs/2010-02/msg00179.php
> http://archives.postgresql.org/pgsql-admin/2009-05/msg00105.php
>
> Unfortunately, it seems that no one has been able to get a stack trace yet.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise Postgres Company
>
