pgAdmin ver 1.10 freezing all too frequently

[Pedro Doria Meunier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time of
inactivity...
Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE

Reproducible by:
- - connect to a db
- - click on any of the db's objects
- - wait a while (1-3 minutes)
- - refresh the object

kaboom. it freezes. have to force termination.

Setting the log to "debug" offers no joy as to discover the cause...

I'm unsure as if it's a pgAdmin problem or rather a connection timeout...
At any rate... does pgAdmin make any attempt to KEEP_ALIVE (the
connection)?

Any insight highly appreciated as this is rather annoying ... ;)

Best regards,
Pedro Doria Meunier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrtaz0ACgkQ2FH5GXCfxAvyrgCeL7uYd7vbicUWxEQcqololsAm
wnwAnRJmDFaL0LFnhU1ntWmqT0WWBSDE
=khpI
-----END PGP SIGNATURE-----


--
Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

[Dave Page-7]

On Sun, Nov 1, 2009 at 11:04 AM, Pedro Doria Meunier
<pdoria@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time of
> inactivity...
> Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE
>
> Reproducible by:
> - - connect to a db
> - - click on any of the db's objects
> - - wait a while (1-3 minutes)
> - - refresh the object
>
> kaboom. it freezes. have to force termination.

I only have 64 bit CentOS 5 here at the moment, but I can't reproduce
on that. Anyone else?

> Setting the log to "debug" offers no joy as to discover the cause...
>
> I'm unsure as if it's a pgAdmin problem or rather a connection timeout...
> At any rate... does pgAdmin make any attempt to KEEP_ALIVE (the
> connection)?

No.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
PGDay.EU 2009 Conference: http://2009.pgday.eu/start

--
Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

[Sachin Srivastava-2]

----- Original Message -----
From: "Dave Page" <dpage@...>
To: "Pedro Doria Meunier" <pdoria@...>
Cc: "pgAdmin Support" <pgadmin-support@...>
Sent: Sunday, November 1, 2009 6:07:39 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi
Subject: Re: [pgadmin-support] pgAdmin ver 1.10 freezing all too frequently

On Sun, Nov 1, 2009 at 11:04 AM, Pedro Doria Meunier
<pdoria@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time of
> inactivity...
> Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE
>
> Reproducible by:
> - - connect to a db
> - - click on any of the db's objects
> - - wait a while (1-3 minutes)
> - - refresh the object
>
> kaboom. it freezes. have to force termination.

I only have 64 bit CentOS 5 here at the moment, but I can't reproduce
on that. Anyone else?

I cannot reproduce the same on my Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE.
(I connected to a db which is running locally) Is it that you got that when you are connected with some remote server?


> Setting the log to "debug" offers no joy as to discover the cause...
>
> I'm unsure as if it's a pgAdmin problem or rather a connection timeout...
> At any rate... does pgAdmin make any attempt to KEEP_ALIVE (the
> connection)?

No.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
PGDay.EU 2009 Conference: http://2009.pgday.eu/start

--
Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

--
Regards,
Sachin Srivastava
www.enterprisedb.com

--
Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

[Pedro Doria Meunier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Sorry forgot to tell it happens on a remote connection... :)

This is AFAICS is most probably a timeout problem.
It makes me wonder if my router isn't dropping idle connections...

Anyway I'm playing with tcp_keepalive_time, tcp_keepalive_intvl values
to see if it solves the problem.
btw:
tcp_keepalive_time = 75
tcp_keepalive_intvl = 60


I'll post my results.

BR,
Pedro Doria Meunier


On 11/01/2009 12:37 PM, Dave Page wrote:

> On Sun, Nov 1, 2009 at 11:04 AM, Pedro Doria Meunier
> <pdoria@...> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>>
>> pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time of
>> inactivity...
>> Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE
>>
>> Reproducible by:
>> - - connect to a db
>> - - click on any of the db's objects
>> - - wait a while (1-3 minutes)
>> - - refresh the object
>>
>> kaboom. it freezes. have to force termination.
>
> I only have 64 bit CentOS 5 here at the moment, but I can't reproduce
> on that. Anyone else?
>
>> Setting the log to "debug" offers no joy as to discover the cause...
>>
>> I'm unsure as if it's a pgAdmin problem or rather a connection timeout...
>> At any rate... does pgAdmin make any attempt to KEEP_ALIVE (the
>> connection)?
>
> No.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrto34ACgkQ2FH5GXCfxAsvuwCePKO950pHKcUx6OCmw5LVy3SM
xLAAn0YRPupAa0JqO8dHcR+0EfDcXyUX
=EIax
-----END PGP SIGNATURE-----


--
Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

[Pedro Doria Meunier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Replying to self:
Altering the tcp_keepalive_time, tcp_keepalive_intvl values *didn't*
solve the problem.


On 11/01/2009 03:04 PM, Pedro Doria Meunier wrote:

>
> Sorry forgot to tell it happens on a remote connection... :)
>
> This is AFAICS is most probably a timeout problem. It makes me
> wonder if my router isn't dropping idle connections...
>
> Anyway I'm playing with tcp_keepalive_time, tcp_keepalive_intvl
> values to see if it solves the problem. btw: tcp_keepalive_time =
> 75 tcp_keepalive_intvl = 60
>
>
> I'll post my results.
>
> BR, Pedro Doria Meunier
>
>
> On 11/01/2009 12:37 PM, Dave Page wrote:
>> On Sun, Nov 1, 2009 at 11:04 AM, Pedro Doria Meunier
>> <pdoria@...> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> Hi,
>>>
>>> pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time
>>> of inactivity... Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE
>>>
>>> Reproducible by: - - connect to a db - - click on any of the
>>> db's objects - - wait a while (1-3 minutes) - - refresh the
>>> object
>>>
>>> kaboom. it freezes. have to force termination.
>
>> I only have 64 bit CentOS 5 here at the moment, but I can't
>> reproduce on that. Anyone else?
>
>>> Setting the log to "debug" offers no joy as to discover the
>>> cause...
>>>
>>> I'm unsure as if it's a pgAdmin problem or rather a connection
> timeout...
>>> At any rate... does pgAdmin make any attempt to KEEP_ALIVE
>>> (the connection)?
>
>> No.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrtq3EACgkQ2FH5GXCfxAuPUQCdExxsfhj3pyrCXuK0MqB0Sm9w
xsIAoI3N5xHOiHlGQC6HfW2BtPXpTtlt
=gNcZ
-----END PGP SIGNATURE-----


--
Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

[Eugene Lisitsky]

I see such problem when remote servers replies slowly.

2009/11/1 Pedro Doria Meunier <pdoria@...>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Replying to self:
Altering the tcp_keepalive_time, tcp_keepalive_intvl values *didn't*
solve the problem.

On 11/01/2009 03:04 PM, Pedro Doria Meunier wrote:
>
> Sorry forgot to tell it happens on a remote connection... :)
>
> This is AFAICS is most probably a timeout problem. It makes me
> wonder if my router isn't dropping idle connections...
>
> Anyway I'm playing with tcp_keepalive_time, tcp_keepalive_intvl
> values to see if it solves the problem. btw: tcp_keepalive_time =
> 75 tcp_keepalive_intvl = 60
>
>
> I'll post my results.
>
> BR, Pedro Doria Meunier
>
>
> On 11/01/2009 12:37 PM, Dave Page wrote:
>> On Sun, Nov 1, 2009 at 11:04 AM, Pedro Doria Meunier
>> <pdoria@...> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> Hi,
>>>
>>> pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time
>>> of inactivity... Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE
>>>
>>> Reproducible by: - - connect to a db - - click on any of the
>>> db's objects - - wait a while (1-3 minutes) - - refresh the
>>> object
>>>
>>> kaboom. it freezes. have to force termination.
>
>> I only have 64 bit CentOS 5 here at the moment, but I can't
>> reproduce on that. Anyone else?
>
>>> Setting the log to "debug" offers no joy as to discover the
>>> cause...
>>>
>>> I'm unsure as if it's a pgAdmin problem or rather a connection
> timeout...
>>> At any rate... does pgAdmin make any attempt to KEEP_ALIVE
>>> (the connection)?
>
>> No.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrtq3EACgkQ2FH5GXCfxAuPUQCdExxsfhj3pyrCXuK0MqB0Sm9w
xsIAoI3N5xHOiHlGQC6HfW2BtPXpTtlt
=gNcZ

-----END PGP SIGNATURE-----


--
Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

--
Yours,
Eugene Lisitsky

[Michael Shapiro-5]

It happens to me quite a lot, as well. I will lose the contents of the SQL window as well when it happens.

It would be good if PgAdmin would automatically try to reconnect (at least once) before giving up.

On Wed, Nov 11, 2009 at 8:08 AM, Eugene Lisitsky <lisitsky@...> wrote:

I see such problem when remote servers replies slowly.

2009/11/1 Pedro Doria Meunier <pdoria@...>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Replying to self:
Altering the tcp_keepalive_time, tcp_keepalive_intvl values *didn't* solve the problem.

On 11/01/2009 03:04 PM, Pedro Doria Meunier wrote:
>
> Sorry forgot to tell it happens on a remote connection... :)
>
> This is AFAICS is most probably a timeout problem. It makes me
> wonder if my router isn't dropping idle connections...
>
> Anyway I'm playing with tcp_keepalive_time, tcp_keepalive_intvl
> values to see if it solves the problem. btw: tcp_keepalive_time =
> 75 tcp_keepalive_intvl = 60
>
>
> I'll post my results.
>
> BR, Pedro Doria Meunier
>
>
> On 11/01/2009 12:37 PM, Dave Page wrote:
>> On Sun, Nov 1, 2009 at 11:04 AM, Pedro Doria Meunier
>> <pdoria@...> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> Hi,
>>>
>>> pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time
>>> of inactivity... Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE
>>>
>>> Reproducible by: - - connect to a db - - click on any of the
>>> db's objects - - wait a while (1-3 minutes) - - refresh the
>>> object
>>>
>>> kaboom. it freezes. have to force termination.
>
>> I only have 64 bit CentOS 5 here at the moment, but I can't
>> reproduce on that. Anyone else?
>
>>> Setting the log to "debug" offers no joy as to discover the
>>> cause...
>>>
>>> I'm unsure as if it's a pgAdmin problem or rather a connection
> timeout...
>>> At any rate... does pgAdmin make any attempt to KEEP_ALIVE
>>> (the connection)?
>
>> No.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrtq3EACgkQ2FH5GXCfxAuPUQCdExxsfhj3pyrCXuK0MqB0Sm9w
xsIAoI3N5xHOiHlGQC6HfW2BtPXpTtlt
=gNcZ

-----END PGP SIGNATURE-----


--

Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

--
Yours,
Eugene Lisitsky

[Michael Shapiro-5]

It just happened again. I ran a query in a window and after it completed I waited 10-15 minutes and ran it again.
I got a connection error. I ran the query again (by hitting the green > icon) and it caused pgAdmin to crash.

Moreover, I was simultaneously running another tool that was connected to a non-Postgres database. After PgAdmin crashed I ran a query in the other tool. It ran fine. This implies that the connection isn't being dropped by my router due to inactivity. It is probably happening within the Postgres server.

I will try to run this test again using PgAdmin and a different tool that can connect to the same Postgres database.

On Wed, Nov 11, 2009 at 8:32 AM, Michael Shapiro <mshapiro51@...> wrote:

It happens to me quite a lot, as well. I will lose the contents of the SQL window as well when it happens.

It would be good if PgAdmin would automatically try to reconnect (at least once) before giving up.

On Wed, Nov 11, 2009 at 8:08 AM, Eugene Lisitsky <lisitsky@...> wrote:

I see such problem when remote servers replies slowly.

2009/11/1 Pedro Doria Meunier <pdoria@...>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Replying to self:
Altering the tcp_keepalive_time, tcp_keepalive_intvl values *didn't* solve the problem.

On 11/01/2009 03:04 PM, Pedro Doria Meunier wrote:
>
> Sorry forgot to tell it happens on a remote connection... :)
>
> This is AFAICS is most probably a timeout problem. It makes me
> wonder if my router isn't dropping idle connections...
>
> Anyway I'm playing with tcp_keepalive_time, tcp_keepalive_intvl
> values to see if it solves the problem. btw: tcp_keepalive_time =
> 75 tcp_keepalive_intvl = 60
>
>
> I'll post my results.
>
> BR, Pedro Doria Meunier
>
>
> On 11/01/2009 12:37 PM, Dave Page wrote:
>> On Sun, Nov 1, 2009 at 11:04 AM, Pedro Doria Meunier
>> <pdoria@...> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> Hi,
>>>
>>> pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time
>>> of inactivity... Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE
>>>
>>> Reproducible by: - - connect to a db - - click on any of the
>>> db's objects - - wait a while (1-3 minutes) - - refresh the
>>> object
>>>
>>> kaboom. it freezes. have to force termination.
>
>> I only have 64 bit CentOS 5 here at the moment, but I can't
>> reproduce on that. Anyone else?
>
>>> Setting the log to "debug" offers no joy as to discover the
>>> cause...
>>>
>>> I'm unsure as if it's a pgAdmin problem or rather a connection
> timeout...
>>> At any rate... does pgAdmin make any attempt to KEEP_ALIVE
>>> (the connection)?
>
>> No.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrtq3EACgkQ2FH5GXCfxAuPUQCdExxsfhj3pyrCXuK0MqB0Sm9w
xsIAoI3N5xHOiHlGQC6HfW2BtPXpTtlt
=gNcZ

-----END PGP SIGNATURE-----


--

Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

--
Yours,
Eugene Lisitsky

[Pedro Doria Meunier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm "glad" :] I'm not alone in this...

It's definitely not the router. It's something else...

For instance:

- - One opens a table. leave it be for some time and the next operation
freezes pgAdmin, especially if one tries to open another database
object (or another database).

- - If the SAME object is closed and then re-opened, no matter what time
it takes, it opens without a problem.

I use pgAdmin *intensively* and it's becoming *inpractical* to work
with it to my great sorrow...

I sure hope the gurus come up with a fix for this... ;)

Best regards,
Pedro Doria Meunier





On 11/11/2009 03:20 PM, Michael Shapiro wrote:

> It just happened again. I ran a query in a window and after it
> completed I waited 10-15 minutes and ran it again. I got a
> connection error. I ran the query again (by hitting the green >
> icon) and it caused pgAdmin to crash.
>
> Moreover, I was simultaneously running another tool that was
> connected to a non-Postgres database. After PgAdmin crashed I ran a
> query in the other tool. It ran fine. This implies that the
> connection isn't being dropped by my router due to inactivity. It
> is probably happening within the Postgres server.
>
> I will try to run this test again using PgAdmin and a different
> tool that can connect to the same Postgres database.
>
>
> On Wed, Nov 11, 2009 at 8:32 AM, Michael Shapiro
> <mshapiro51@... <mailto:mshapiro51@...>> wrote:
>
> It happens to me quite a lot, as well. I will lose the contents of
> the SQL window as well when it happens.
>
> It would be good if PgAdmin would automatically try to reconnect
> (at least once) before giving up.
>
>
> On Wed, Nov 11, 2009 at 8:08 AM, Eugene Lisitsky
> <lisitsky@... <mailto:lisitsky@...>> wrote:
>
>
> I see such problem when remote servers replies slowly.
>
>
> 2009/11/1 Pedro Doria Meunier <pdoria@...
> <mailto:pdoria@...>>
>
> Replying to self: Altering the tcp_keepalive_time,
> tcp_keepalive_intvl values *didn't* solve the problem.
>
>
> On 11/01/2009 03:04 PM, Pedro Doria Meunier wrote:
>
>> Sorry forgot to tell it happens on a remote connection... :)
>
>> This is AFAICS is most probably a timeout problem. It makes me
>> wonder if my router isn't dropping idle connections...
>
>> Anyway I'm playing with tcp_keepalive_time, tcp_keepalive_intvl
>> values to see if it solves the problem. btw: tcp_keepalive_time
>> = 75 tcp_keepalive_intvl = 60
>
>
>> I'll post my results.
>
>> BR, Pedro Doria Meunier
>
>
>> On 11/01/2009 12:37 PM, Dave Page wrote:
>>> On Sun, Nov 1, 2009 at 11:04 AM, Pedro Doria Meunier
>>> <pdoria@... <mailto:pdoria@...>> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>
>>>> Hi,
>>>>
>>>> pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time
>>>> of inactivity... Fedora 11 - kernel
>>>> 2.6.30.9-90.fc11.i686.PAE
>>>>
>>>> Reproducible by: - - connect to a db - - click on any of the
>>>> db's objects - - wait a while (1-3 minutes) - - refresh the
>>>> object
>>>>
>>>> kaboom. it freezes. have to force termination.
>
>>> I only have 64 bit CentOS 5 here at the moment, but I can't
>>> reproduce on that. Anyone else?
>
>>>> Setting the log to "debug" offers no joy as to discover the
>>>> cause...
>>>>
>>>> I'm unsure as if it's a pgAdmin problem or rather a
>>>> connection
>> timeout...
>>>> At any rate... does pgAdmin make any attempt to KEEP_ALIVE
>>>> (the connection)?
>
>>> No.
>

- --

Sent via pgadmin-support mailing list (pgadmin-support@...
<mailto:pgadmin-support@...>)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support




> -- Yours, Eugene Lisitsky



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr62hAACgkQ2FH5GXCfxAtuIACbBJGfLn7Ohm9joY1t5UWBJ2Yp
ZMQAn1rfEXf4w3xTvYvayyuOtE53WXG7
=XkJO
-----END PGP SIGNATURE-----


--
Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

[Dave Page-7]

On Wed, Nov 11, 2009 at 3:36 PM, Pedro Doria Meunier
<pdoria@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm "glad" :] I'm not alone in this...
>
> It's definitely not the router. It's something else...
>
> For instance:
>
> - - One opens a table. leave it be for some time and the next operation
> freezes pgAdmin, especially if one tries to open another database
> object (or another database).
>
> - - If the SAME object is closed and then re-opened, no matter what time
> it takes, it opens without a problem.
>
> I use pgAdmin *intensively* and it's becoming *inpractical* to work
> with it to my great sorrow...
>
> I sure hope the gurus come up with a fix for this... ;)

Being completely unable to reproduce the problem makes that extremely
unlikely I'm afraid.

Can you reproduce the problem with a debug-enabled build, and then
attach a debugger and get a backtrace?


--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

[Pedro Doria Meunier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Dave

Did as you asked...

problem:
./pgadmin3: error while loading shared libraries:
libwx_gtk2ud_stc-2.8.so.0: cannot open shared object file: No such
file or directory
(on execution, after compilation)

This library is nowhere to be found...

Do you by any change have a debug-enable version of pgadmin3 on your
hands? ;)

BR,
Pedro Doria Meunier

On 11/11/2009 03:39 PM, Dave Page wrote:

> On Wed, Nov 11, 2009 at 3:36 PM, Pedro Doria Meunier
> <pdoria@...> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> I'm "glad" :] I'm not alone in this...
>>
>> It's definitely not the router. It's something else...
>>
>> For instance:
>>
>> - - One opens a table. leave it be for some time and the next
>> operation freezes pgAdmin, especially if one tries to open
>> another database object (or another database).
>>
>> - - If the SAME object is closed and then re-opened, no matter
>> what time it takes, it opens without a problem.
>>
>> I use pgAdmin *intensively* and it's becoming *inpractical* to
>> work with it to my great sorrow...
>>
>> I sure hope the gurus come up with a fix for this... ;)
>
> Being completely unable to reproduce the problem makes that
> extremely unlikely I'm afraid.
>
> Can you reproduce the problem with a debug-enabled build, and then
> attach a debugger and get a backtrace?
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr7CQAACgkQ2FH5GXCfxAuj8wCgkigdsRT7BK+Cy/JD91vNjn1+
IDYAn32nePEO0sJmLMfevV3a+U72DmfW
=D3I8
-----END PGP SIGNATURE-----


--
Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

[Pedro Doria Meunier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok. please disregard that last one... :)

This is the last output of valgrind before I had to kill pgadmin:

==671== Thread 2:
==671== Syscall param write(buf) points to uninitialised byte(s)
==671==    at 0xBC4F4B: (within /lib/libpthread-2.10.1.so)
==671==    by 0x6149EE: BIO_write (in /usr/lib/libcrypto.so.0.9.8k)
==671==    by 0x742F93: ssl3_write_pending (in /usr/lib/libssl.so.0.9.8k)
==671==    by 0x743350: (within /usr/lib/libssl.so.0.9.8k)
==671==    by 0x743688: ssl3_write_bytes (in /usr/lib/libssl.so.0.9.8k)
==671==    by 0x7408A0: ssl3_write (in /usr/lib/libssl.so.0.9.8k)
==671==    by 0x7538B8: SSL_write (in /usr/lib/libssl.so.0.9.8k)
==671==    by 0x4B5995C: (within /usr/lib/libpq.so.5.1)
==671==    by 0x4B51316: (within /usr/lib/libpq.so.5.1)
==671==    by 0x4B4EBE7: PQsendQuery (in /usr/lib/libpq.so.5.1)
==671==    by 0x80D337B: pgQueryThread::execute() (pgQueryThread.cpp:104)
==671==    by 0x80D3A34: pgQueryThread::Entry() (pgQueryThread.cpp:210)
==671==  Address 0x933685d is 5 bytes inside a block of size 18,698
alloc'd
==671==    at 0x4006F3D: malloc (vg_replace_malloc.c:207)
==671==    by 0x6A05CD: (within /usr/lib/libcrypto.so.0.9.8k)
==671==    by 0x6A0C5B: CRYPTO_malloc (in /usr/lib/libcrypto.so.0.9.8k)
==671==    by 0x744BF8: ssl3_setup_buffers (in /usr/lib/libssl.so.0.9.8k)
==671==    by 0x73FDEF: ssl3_connect (in /usr/lib/libssl.so.0.9.8k)
==671==    by 0x753CA9: SSL_connect (in /usr/lib/libssl.so.0.9.8k)
==671==    by 0x4B59EFA: (within /usr/lib/libpq.so.5.1)
==671==    by 0x4B4A165: PQconnectPoll (in /usr/lib/libpq.so.5.1)
==671==    by 0x4B4AD67: (within /usr/lib/libpq.so.5.1)
==671==    by 0x4B4D342: PQconnectdb (in /usr/lib/libpq.so.5.1)
==671==    by 0x80CC832: pgConn::pgConn(wxString const&, wxString
const&, wxString const&, wxString const&, int, int, unsigned long)
(pgConn.cpp:175)
==671==    by 0x82F8778: pgServer::CreateConn(wxString, unsigned long)
(pgServer.cpp:140)
- --671-- memcheck GC: 131072 nodes, 114351 survivors ( 87.2%)
- --671-- memcheck GC: increase table size to 262144
Killed


At this point the app is irresponsive after I tried to access another
of the DB's objects..

Please tell me what more can I do on this end... ;)

BR,
Pedro Doria Meunier





On 11/11/2009 06:57 PM, Pedro Doria Meunier wrote:

> Hi Dave
>
> Did as you asked...
>
> problem: ./pgadmin3: error while loading shared libraries:
> libwx_gtk2ud_stc-2.8.so.0: cannot open shared object file: No such
> file or directory (on execution, after compilation)
>
> This library is nowhere to be found...
>
> Do you by any change have a debug-enable version of pgadmin3 on
> your hands? ;)
>
> BR, Pedro Doria Meunier
>
> On 11/11/2009 03:39 PM, Dave Page wrote:
>> On Wed, Nov 11, 2009 at 3:36 PM, Pedro Doria Meunier
>> <pdoria@...> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> I'm "glad" :] I'm not alone in this...
>>>
>>> It's definitely not the router. It's something else...
>>>
>>> For instance:
>>>
>>> - - One opens a table. leave it be for some time and the next
>>> operation freezes pgAdmin, especially if one tries to open
>>> another database object (or another database).
>>>
>>> - - If the SAME object is closed and then re-opened, no matter
>>> what time it takes, it opens without a problem.
>>>
>>> I use pgAdmin *intensively* and it's becoming *inpractical* to
>>> work with it to my great sorrow...
>>>
>>> I sure hope the gurus come up with a fix for this... ;)
>
>> Being completely unable to reproduce the problem makes that
>> extremely unlikely I'm afraid.
>
>> Can you reproduce the problem with a debug-enabled build, and
>> then attach a debugger and get a backtrace?
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr7F+IACgkQ2FH5GXCfxAu5NwCdFdY0s37PXJN4GkG4UEyYyzKD
IaEAn2zjsByg761rXDTF5u09zRU3em99
=fJnB
-----END PGP SIGNATURE-----


--
Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

[Pedro Doria Meunier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok...

I've tried with valgrind and gdb attached ... no luck
with gdb alone and trying to get a stack trace ... no luck

whatever is happening with pgadmin3 under the beforementioned
conditions *freezes* everything ...

BR,
Pedro


On 11/11/2009 08:00 PM, Pedro Doria Meunier wrote:

> Ok. please disregard that last one... :)
>
> This is the last output of valgrind before I had to kill pgadmin:
>
> ==671== Thread 2: ==671== Syscall param write(buf) points to
> uninitialised byte(s) ==671==    at 0xBC4F4B: (within
> /lib/libpthread-2.10.1.so) ==671==    by 0x6149EE: BIO_write (in
> /usr/lib/libcrypto.so.0.9.8k) ==671==    by 0x742F93:
> ssl3_write_pending (in /usr/lib/libssl.so.0.9.8k) ==671==    by
> 0x743350: (within /usr/lib/libssl.so.0.9.8k) ==671==    by
> 0x743688: ssl3_write_bytes (in /usr/lib/libssl.so.0.9.8k) ==671==
> by 0x7408A0: ssl3_write (in /usr/lib/libssl.so.0.9.8k) ==671==
> by 0x7538B8: SSL_write (in /usr/lib/libssl.so.0.9.8k) ==671==    by
> 0x4B5995C: (within /usr/lib/libpq.so.5.1) ==671==    by 0x4B51316:
> (within /usr/lib/libpq.so.5.1) ==671==    by 0x4B4EBE7: PQsendQuery
> (in /usr/lib/libpq.so.5.1) ==671==    by 0x80D337B:
> pgQueryThread::execute() (pgQueryThread.cpp:104) ==671==    by
> 0x80D3A34: pgQueryThread::Entry() (pgQueryThread.cpp:210) ==671==
> Address 0x933685d is 5 bytes inside a block of size 18,698 alloc'd
> ==671==    at 0x4006F3D: malloc (vg_replace_malloc.c:207) ==671==
> by 0x6A05CD: (within /usr/lib/libcrypto.so.0.9.8k) ==671==    by
> 0x6A0C5B: CRYPTO_malloc (in /usr/lib/libcrypto.so.0.9.8k) ==671==
> by 0x744BF8: ssl3_setup_buffers (in /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x73FDEF: ssl3_connect (in
> /usr/lib/libssl.so.0.9.8k) ==671==    by 0x753CA9: SSL_connect (in
> /usr/lib/libssl.so.0.9.8k) ==671==    by 0x4B59EFA: (within
> /usr/lib/libpq.so.5.1) ==671==    by 0x4B4A165: PQconnectPoll (in
> /usr/lib/libpq.so.5.1) ==671==    by 0x4B4AD67: (within
> /usr/lib/libpq.so.5.1) ==671==    by 0x4B4D342: PQconnectdb (in
> /usr/lib/libpq.so.5.1) ==671==    by 0x80CC832:
> pgConn::pgConn(wxString const&, wxString const&, wxString const&,
> wxString const&, int, int, unsigned long) (pgConn.cpp:175) ==671==
> by 0x82F8778: pgServer::CreateConn(wxString, unsigned long)
> (pgServer.cpp:140) --671-- memcheck GC: 131072 nodes, 114351
> survivors ( 87.2%) --671-- memcheck GC: increase table size to
> 262144 Killed
>
>
> At this point the app is irresponsive after I tried to access
> another of the DB's objects..
>
> Please tell me what more can I do on this end... ;)
>
> BR, Pedro Doria Meunier
>
>
>
>
>
> On 11/11/2009 06:57 PM, Pedro Doria Meunier wrote:
>> Hi Dave
>
>> Did as you asked...
>
>> problem: ./pgadmin3: error while loading shared libraries:
>> libwx_gtk2ud_stc-2.8.so.0: cannot open shared object file: No
>> such file or directory (on execution, after compilation)
>
>> This library is nowhere to be found...
>
>> Do you by any change have a debug-enable version of pgadmin3 on
>> your hands? ;)
>
>> BR, Pedro Doria Meunier
>
>> On 11/11/2009 03:39 PM, Dave Page wrote:
>>> On Wed, Nov 11, 2009 at 3:36 PM, Pedro Doria Meunier
>>> <pdoria@...> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>
>>>> I'm "glad" :] I'm not alone in this...
>>>>
>>>> It's definitely not the router. It's something else...
>>>>
>>>> For instance:
>>>>
>>>> - - One opens a table. leave it be for some time and the
>>>> next operation freezes pgAdmin, especially if one tries to
>>>> open another database object (or another database).
>>>>
>>>> - - If the SAME object is closed and then re-opened, no
>>>> matter what time it takes, it opens without a problem.
>>>>
>>>> I use pgAdmin *intensively* and it's becoming *inpractical*
>>>> to work with it to my great sorrow...
>>>>
>>>> I sure hope the gurus come up with a fix for this... ;)
>
>>> Being completely unable to reproduce the problem makes that
>>> extremely unlikely I'm afraid.
>
>>> Can you reproduce the problem with a debug-enabled build, and
>>> then attach a debugger and get a backtrace?
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr7MfgACgkQ2FH5GXCfxAub6QCdEabLsGFaBwUTrou2qANzXGFk
FV8AoKOBV5q0BjIgF/y6Yc/L5AZSOV59
=OEwJ
-----END PGP SIGNATURE-----


--
Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

[Michael Shapiro-5]

I was able to reproduce the problem within PgAdmin as well as with another (java-based) tool connecting to the same database from the same (Windows XP) machine.

I opened an query window and ran a query (that did not take long to complete) in both tools. I then waited 1/2 hour and ran the query again. PgAdmin and the other tool both saw that the connection had been dropped. PgAdmin will continue to run and work if I open a new query window, but if I insist on running the query again in the same window it fails. Moreover, if I insist twice, PgAdmin crashes. The java-based tool restablished the connection, and gets the query results fine, but detects an I/O error while sending the query to the postgres backend. It will continue to function and run queries and get results, but each time it sees an I/O error.

17:05:35 [ERROR AWT-EventQueue-1 H.?] isEditable Error: An I/O error occured while sending to the backend.


I realize that unless the development team can reproduce the problem, it is hard to fix, but at least it appears that the connection being dropped is not caused by PgAdmin itself. Seems like the postgres server may be doing it. I have asked the server admins if the server does automatic timeouts for idle connections.

On Wed, Nov 11, 2009 at 9:20 AM, Michael Shapiro <mshapiro51@...> wrote:

It just happened again. I ran a query in a window and after it completed I waited 10-15 minutes and ran it again.
I got a connection error. I ran the query again (by hitting the green > icon) and it caused pgAdmin to crash.

Moreover, I was simultaneously running another tool that was connected to a non-Postgres database. After PgAdmin crashed I ran a query in the other tool. It ran fine. This implies that the connection isn't being dropped by my router due to inactivity. It is probably happening within the Postgres server.

I will try to run this test again using PgAdmin and a different tool that can connect to the same Postgres database.

On Wed, Nov 11, 2009 at 8:32 AM, Michael Shapiro <mshapiro51@...> wrote:

It happens to me quite a lot, as well. I will lose the contents of the SQL window as well when it happens.

It would be good if PgAdmin would automatically try to reconnect (at least once) before giving up.

On Wed, Nov 11, 2009 at 8:08 AM, Eugene Lisitsky <lisitsky@...> wrote:

I see such problem when remote servers replies slowly.

2009/11/1 Pedro Doria Meunier <pdoria@...>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Replying to self:
Altering the tcp_keepalive_time, tcp_keepalive_intvl values *didn't* solve the problem.

On 11/01/2009 03:04 PM, Pedro Doria Meunier wrote:
>
> Sorry forgot to tell it happens on a remote connection... :)
>
> This is AFAICS is most probably a timeout problem. It makes me
> wonder if my router isn't dropping idle connections...
>
> Anyway I'm playing with tcp_keepalive_time, tcp_keepalive_intvl
> values to see if it solves the problem. btw: tcp_keepalive_time =
> 75 tcp_keepalive_intvl = 60
>
>
> I'll post my results.
>
> BR, Pedro Doria Meunier
>
>
> On 11/01/2009 12:37 PM, Dave Page wrote:
>> On Sun, Nov 1, 2009 at 11:04 AM, Pedro Doria Meunier
>> <pdoria@...> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> Hi,
>>>
>>> pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time
>>> of inactivity... Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE
>>>
>>> Reproducible by: - - connect to a db - - click on any of the
>>> db's objects - - wait a while (1-3 minutes) - - refresh the
>>> object
>>>
>>> kaboom. it freezes. have to force termination.
>
>> I only have 64 bit CentOS 5 here at the moment, but I can't
>> reproduce on that. Anyone else?
>
>>> Setting the log to "debug" offers no joy as to discover the
>>> cause...
>>>
>>> I'm unsure as if it's a pgAdmin problem or rather a connection
> timeout...
>>> At any rate... does pgAdmin make any attempt to KEEP_ALIVE
>>> (the connection)?
>
>> No.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrtq3EACgkQ2FH5GXCfxAuPUQCdExxsfhj3pyrCXuK0MqB0Sm9w
xsIAoI3N5xHOiHlGQC6HfW2BtPXpTtlt
=gNcZ

-----END PGP SIGNATURE-----


--

Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

--
Yours,
Eugene Lisitsky

[Michael Shapiro-5]

I checked the server logs and found messages like this:

2009-11-11 15:08:36 PSTLOG:  could not receive data from client: Connection reset by peer
2009-11-11 16:18:11 PSTLOG:  could not receive data from client: Connection timed out

I do not know if this means that the server did the disconnect or the network did it (I suspect the network).
This seems to imply that we are at the mercy of either the network admins or the server admins. In either case, it is problematic since a lost connection is not handled well in PgAdmin.

On Wed, Nov 11, 2009 at 5:11 PM, Michael Shapiro <mshapiro51@...> wrote:

I was able to reproduce the problem within PgAdmin as well as with another (java-based) tool connecting to the same database from the same (Windows XP) machine.

I opened an query window and ran a query (that did not take long to complete) in both tools. I then waited 1/2 hour and ran the query again. PgAdmin and the other tool both saw that the connection had been dropped. PgAdmin will continue to run and work if I open a new query window, but if I insist on running the query again in the same window it fails. Moreover, if I insist twice, PgAdmin crashes. The java-based tool re-established the connection, and gets the query results fine, but detects an I/O error while sending the query to the postgres backend. It will continue to function and run queries and get results, but each time it sees an I/O error.

17:05:35 [ERROR AWT-EventQueue-1 H.?] isEditable Error: An I/O error occurred while sending to the backend.


I realize that unless the development team can reproduce the problem, it is hard to fix, but at least it appears that the connection being dropped is not caused by PgAdmin itself. Seems like the postgres server may be doing it. I have asked the server admins if the server does automatic timeouts for idle connections.

On Wed, Nov 11, 2009 at 9:20 AM, Michael Shapiro <mshapiro51@...> wrote:

It just happened again. I ran a query in a window and after it completed I waited 10-15 minutes and ran it again.
I got a connection error. I ran the query again (by hitting the green > icon) and it caused pgAdmin to crash.

Moreover, I was simultaneously running another tool that was connected to a non-Postgres database. After PgAdmin crashed I ran a query in the other tool. It ran fine. This implies that the connection isn't being dropped by my router due to inactivity. It is probably happening within the Postgres server.

I will try to run this test again using PgAdmin and a different tool that can connect to the same Postgres database.

On Wed, Nov 11, 2009 at 8:32 AM, Michael Shapiro <mshapiro51@...> wrote:

It happens to me quite a lot, as well. I will lose the contents of the SQL window as well when it happens.

It would be good if PgAdmin would automatically try to reconnect (at least once) before giving up.

On Wed, Nov 11, 2009 at 8:08 AM, Eugene Lisitsky <lisitsky@...> wrote:

I see such problem when remote servers replies slowly.

2009/11/1 Pedro Doria Meunier <pdoria@...>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Replying to self:
Altering the tcp_keepalive_time, tcp_keepalive_intvl values *didn't* solve the problem.

On 11/01/2009 03:04 PM, Pedro Doria Meunier wrote:
>
> Sorry forgot to tell it happens on a remote connection... :)
>
> This is AFAICS is most probably a timeout problem. It makes me
> wonder if my router isn't dropping idle connections...
>
> Anyway I'm playing with tcp_keepalive_time, tcp_keepalive_intvl
> values to see if it solves the problem. btw: tcp_keepalive_time =
> 75 tcp_keepalive_intvl = 60
>
>
> I'll post my results.
>
> BR, Pedro Doria Meunier
>
>
> On 11/01/2009 12:37 PM, Dave Page wrote:
>> On Sun, Nov 1, 2009 at 11:04 AM, Pedro Doria Meunier
>> <pdoria@...> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> Hi,
>>>
>>> pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time
>>> of inactivity... Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE
>>>
>>> Reproducible by: - - connect to a db - - click on any of the
>>> db's objects - - wait a while (1-3 minutes) - - refresh the
>>> object
>>>
>>> kaboom. it freezes. have to force termination.
>
>> I only have 64 bit CentOS 5 here at the moment, but I can't
>> reproduce on that. Anyone else?
>
>>> Setting the log to "debug" offers no joy as to discover the
>>> cause...
>>>
>>> I'm unsure as if it's a pgAdmin problem or rather a connection
> timeout...
>>> At any rate... does pgAdmin make any attempt to KEEP_ALIVE
>>> (the connection)?
>
>> No.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrtq3EACgkQ2FH5GXCfxAuPUQCdExxsfhj3pyrCXuK0MqB0Sm9w
xsIAoI3N5xHOiHlGQC6HfW2BtPXpTtlt
=gNcZ

-----END PGP SIGNATURE-----


--

Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

--
Yours,
Eugene Lisitsky

[Michael Shapiro-5]

I did a bit more checking and there appears to be some server configurations that may affect keeping the connection alive:

tcp_keepalives_idle (integer)

On systems that support the TCP_KEEPIDLE socket option, specifies the number of seconds between sending keepalives on an otherwise idle connection. A value of zero uses the system default. If TCP_KEEPIDLE is not supported, this parameter must be zero. This parameter is ignored for connections made via a Unix-domain socket.

tcp_keepalives_interval (integer)

On systems that support the TCP_KEEPINTVL socket option, specifies how long, in seconds, to wait for a response to a keepalive before retransmitting. A value of zero uses the system default. If TCP_KEEPINTVL is not supported, this parameter must be zero. This parameter is ignored for connections made via a Unix-domain socket.

tcp_keepalives_count (integer)

On systems that support the TCP_KEEPCNT socket option, specifies how many keepalives can be lost before the connection is considered dead. A value of zero uses the system default. If TCP_KEEPCNT is not supported, this parameter must be zero. This parameter is ignored for connections made via a Unix-domain socket.

You can determine the settings for a server by running the following:

select * from pg_settings where name like 'tcp%'

On Wed, Nov 11, 2009 at 9:21 PM, Michael Shapiro <mshapiro51@...> wrote:

I checked the server logs and found messages like this:

2009-11-11 15:08:36 PSTLOG:  could not receive data from client: Connection reset by peer
2009-11-11 16:18:11 PSTLOG:  could not receive data from client: Connection timed out

I do not know if this means that the server did the disconnect or the network did it (I suspect the network).
This seems to imply that we are at the mercy of either the network admins or the server admins. In either case, it is problematic since a lost connection is not handled well in PgAdmin.

On Wed, Nov 11, 2009 at 5:11 PM, Michael Shapiro <mshapiro51@...> wrote:

I was able to reproduce the problem within PgAdmin as well as with another (java-based) tool connecting to the same database from the same (Windows XP) machine.

I opened an query window and ran a query (that did not take long to complete) in both tools. I then waited 1/2 hour and ran the query again. PgAdmin and the other tool both saw that the connection had been dropped. PgAdmin will continue to run and work if I open a new query window, but if I insist on running the query again in the same window it fails. Moreover, if I insist twice, PgAdmin crashes. The java-based tool re-established the connection, and gets the query results fine, but detects an I/O error while sending the query to the postgres backend. It will continue to function and run queries and get results, but each time it sees an I/O error.

17:05:35 [ERROR AWT-EventQueue-1 H.?] isEditable Error: An I/O error occurred while sending to the backend.

I realize that unless the development team can reproduce the problem, it is hard to fix, but at least it appears that the connection being dropped is not caused by PgAdmin itself. Seems like the postgres server may be doing it. I have asked the server admins if the server does automatic timeouts for idle connections.

On Wed, Nov 11, 2009 at 9:20 AM, Michael Shapiro <mshapiro51@...> wrote:

It just happened again. I ran a query in a window and after it completed I waited 10-15 minutes and ran it again.
I got a connection error. I ran the query again (by hitting the green > icon) and it caused pgAdmin to crash.

Moreover, I was simultaneously running another tool that was connected to a non-Postgres database. After PgAdmin crashed I ran a query in the other tool. It ran fine. This implies that the connection isn't being dropped by my router due to inactivity. It is probably happening within the Postgres server.

I will try to run this test again using PgAdmin and a different tool that can connect to the same Postgres database.

On Wed, Nov 11, 2009 at 8:32 AM, Michael Shapiro <mshapiro51@...> wrote:

It happens to me quite a lot, as well. I will lose the contents of the SQL window as well when it happens.

It would be good if PgAdmin would automatically try to reconnect (at least once) before giving up.

On Wed, Nov 11, 2009 at 8:08 AM, Eugene Lisitsky <lisitsky@...> wrote:

I see such problem when remote servers replies slowly.

2009/11/1 Pedro Doria Meunier <pdoria@...>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Replying to self:
Altering the tcp_keepalive_time, tcp_keepalive_intvl values *didn't* solve the problem.

On 11/01/2009 03:04 PM, Pedro Doria Meunier wrote:
>
> Sorry forgot to tell it happens on a remote connection... :)
>
> This is AFAICS is most probably a timeout problem. It makes me
> wonder if my router isn't dropping idle connections...
>
> Anyway I'm playing with tcp_keepalive_time, tcp_keepalive_intvl
> values to see if it solves the problem. btw: tcp_keepalive_time =
> 75 tcp_keepalive_intvl = 60
>
>
> I'll post my results.
>
> BR, Pedro Doria Meunier
>
>
> On 11/01/2009 12:37 PM, Dave Page wrote:
>> On Sun, Nov 1, 2009 at 11:04 AM, Pedro Doria Meunier
>> <pdoria@...> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> Hi,
>>>
>>> pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time
>>> of inactivity... Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE
>>>
>>> Reproducible by: - - connect to a db - - click on any of the
>>> db's objects - - wait a while (1-3 minutes) - - refresh the
>>> object
>>>
>>> kaboom. it freezes. have to force termination.
>
>> I only have 64 bit CentOS 5 here at the moment, but I can't
>> reproduce on that. Anyone else?
>
>>> Setting the log to "debug" offers no joy as to discover the
>>> cause...
>>>
>>> I'm unsure as if it's a pgAdmin problem or rather a connection
> timeout...
>>> At any rate... does pgAdmin make any attempt to KEEP_ALIVE
>>> (the connection)?
>
>> No.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrtq3EACgkQ2FH5GXCfxAuPUQCdExxsfhj3pyrCXuK0MqB0Sm9w
xsIAoI3N5xHOiHlGQC6HfW2BtPXpTtlt
=gNcZ

-----END PGP SIGNATURE-----


--

Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

--
Yours,
Eugene Lisitsky

[Dave Page-7]

On Wed, Nov 11, 2009 at 6:57 PM, Pedro Doria Meunier
<pdoria@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Dave
>
> Did as you asked...
>
> problem:
> ./pgadmin3: error while loading shared libraries:
> libwx_gtk2ud_stc-2.8.so.0: cannot open shared object file: No such
> file or directory
> (on execution, after compilation)
>
> This library is nowhere to be found...

Looks like you're missing the wxSTC contrib module. That might be a
separate package on whatever OS you're using.

> Do you by any change have a debug-enable version of pgadmin3 on your
> hands? ;)

I have one for Mac OS X Snow Leopard, or Windows....

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

[Dave Page-7]

On Wed, Nov 11, 2009 at 8:00 PM, Pedro Doria Meunier
<pdoria@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ok. please disregard that last one... :)
>
> This is the last output of valgrind before I had to kill pgadmin:
>
> ==671== Thread 2:
> ==671== Syscall param write(buf) points to uninitialised byte(s)
> ==671==    at 0xBC4F4B: (within /lib/libpthread-2.10.1.so)
> ==671==    by 0x6149EE: BIO_write (in /usr/lib/libcrypto.so.0.9.8k)
> ==671==    by 0x742F93: ssl3_write_pending (in /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x743350: (within /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x743688: ssl3_write_bytes (in /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x7408A0: ssl3_write (in /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x7538B8: SSL_write (in /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x4B5995C: (within /usr/lib/libpq.so.5.1)
> ==671==    by 0x4B51316: (within /usr/lib/libpq.so.5.1)
> ==671==    by 0x4B4EBE7: PQsendQuery (in /usr/lib/libpq.so.5.1)
> ==671==    by 0x80D337B: pgQueryThread::execute() (pgQueryThread.cpp:104)
> ==671==    by 0x80D3A34: pgQueryThread::Entry() (pgQueryThread.cpp:210)
> ==671==  Address 0x933685d is 5 bytes inside a block of size 18,698
> alloc'd
> ==671==    at 0x4006F3D: malloc (vg_replace_malloc.c:207)
> ==671==    by 0x6A05CD: (within /usr/lib/libcrypto.so.0.9.8k)
> ==671==    by 0x6A0C5B: CRYPTO_malloc (in /usr/lib/libcrypto.so.0.9.8k)
> ==671==    by 0x744BF8: ssl3_setup_buffers (in /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x73FDEF: ssl3_connect (in /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x753CA9: SSL_connect (in /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x4B59EFA: (within /usr/lib/libpq.so.5.1)
> ==671==    by 0x4B4A165: PQconnectPoll (in /usr/lib/libpq.so.5.1)
> ==671==    by 0x4B4AD67: (within /usr/lib/libpq.so.5.1)
> ==671==    by 0x4B4D342: PQconnectdb (in /usr/lib/libpq.so.5.1)
> ==671==    by 0x80CC832: pgConn::pgConn(wxString const&, wxString
> const&, wxString const&, wxString const&, int, int, unsigned long)
> (pgConn.cpp:175)
> ==671==    by 0x82F8778: pgServer::CreateConn(wxString, unsigned long)
> (pgServer.cpp:140)
> - --671-- memcheck GC: 131072 nodes, 114351 survivors ( 87.2%)
> - --671-- memcheck GC: increase table size to 262144
> Killed
>

Can you reproduce the problem with SSL disabled?


--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

[Pedro Doria Meunier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave,

With SSL disable it's the same thing...

BR,
Pedro.


On 11/12/2009 09:22 AM, Dave Page wrote:

> On Wed, Nov 11, 2009 at 8:00 PM, Pedro Doria Meunier
> <pdoria@...> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Ok. please disregard that last one... :)
>>
>> This is the last output of valgrind before I had to kill pgadmin:
>>
>> ==671== Thread 2:
>> ==671== Syscall param write(buf) points to uninitialised byte(s)
>> ==671==    at 0xBC4F4B: (within /lib/libpthread-2.10.1.so)
>> ==671==    by 0x6149EE: BIO_write (in /usr/lib/libcrypto.so.0.9.8k)
>> ==671==    by 0x742F93: ssl3_write_pending (in /usr/lib/libssl.so.0.9.8k)
>> ==671==    by 0x743350: (within /usr/lib/libssl.so.0.9.8k)
>> ==671==    by 0x743688: ssl3_write_bytes (in /usr/lib/libssl.so.0.9.8k)
>> ==671==    by 0x7408A0: ssl3_write (in /usr/lib/libssl.so.0.9.8k)
>> ==671==    by 0x7538B8: SSL_write (in /usr/lib/libssl.so.0.9.8k)
>> ==671==    by 0x4B5995C: (within /usr/lib/libpq.so.5.1)
>> ==671==    by 0x4B51316: (within /usr/lib/libpq.so.5.1)
>> ==671==    by 0x4B4EBE7: PQsendQuery (in /usr/lib/libpq.so.5.1)
>> ==671==    by 0x80D337B: pgQueryThread::execute() (pgQueryThread.cpp:104)
>> ==671==    by 0x80D3A34: pgQueryThread::Entry() (pgQueryThread.cpp:210)
>> ==671==  Address 0x933685d is 5 bytes inside a block of size 18,698
>> alloc'd
>> ==671==    at 0x4006F3D: malloc (vg_replace_malloc.c:207)
>> ==671==    by 0x6A05CD: (within /usr/lib/libcrypto.so.0.9.8k)
>> ==671==    by 0x6A0C5B: CRYPTO_malloc (in /usr/lib/libcrypto.so.0.9.8k)
>> ==671==    by 0x744BF8: ssl3_setup_buffers (in /usr/lib/libssl.so.0.9.8k)
>> ==671==    by 0x73FDEF: ssl3_connect (in /usr/lib/libssl.so.0.9.8k)
>> ==671==    by 0x753CA9: SSL_connect (in /usr/lib/libssl.so.0.9.8k)
>> ==671==    by 0x4B59EFA: (within /usr/lib/libpq.so.5.1)
>> ==671==    by 0x4B4A165: PQconnectPoll (in /usr/lib/libpq.so.5.1)
>> ==671==    by 0x4B4AD67: (within /usr/lib/libpq.so.5.1)
>> ==671==    by 0x4B4D342: PQconnectdb (in /usr/lib/libpq.so.5.1)
>> ==671==    by 0x80CC832: pgConn::pgConn(wxString const&, wxString
>> const&, wxString const&, wxString const&, int, int, unsigned long)
>> (pgConn.cpp:175)
>> ==671==    by 0x82F8778: pgServer::CreateConn(wxString, unsigned long)
>> (pgServer.cpp:140)
>> - --671-- memcheck GC: 131072 nodes, 114351 survivors ( 87.2%)
>> - --671-- memcheck GC: increase table size to 262144
>> Killed
>>
>
> Can you reproduce the problem with SSL disabled?
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr75lsACgkQ2FH5GXCfxAs7cwCfaoGfyuuiEXrV9EI6W0ABnhLk
BK8AoL5qz9GDkXbKCafMULl/IWtPElp6
=ZdL9
-----END PGP SIGNATURE-----


--
Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

[Dave Page-7]

On Thu, Nov 12, 2009 at 10:41 AM, Pedro Doria Meunier
<pdoria@...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dave,
>
> With SSL disable it's the same thing...

Can you get the trace please?


--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support