Thread: Reconnection problem.
Hello there, First of all - Happy Easter to all of the readers! I've got a question related to the reconnection procedure, when connection lost. It is quite easy to do in the main PgAdmin window, but how do I reconnect to the same database when operating within SQL Query window? When connection lost, I do can connect to the other databases using combobox located on the toolbar, but can't reconnect to the one that was used before connection was lost. Steps to reproduce: 1. Configure connections at least to the two databases, connect to the first of them. 2. Open SQL Query window, write and execute some query. 3. Disconnect and reconnet your network connection. 4. Your connection is dropped - try to reconnect -> impossible, but you still can connect to the other database than in point 1. The configurations affected are (as tested): - Windows 7 x64, PgAdmin 1.12.1 - Fedora 14 x86_64, PgAdmin 1.12.0 Thanks for any help, Piotr -- -------------------------------------------------------------- "TECHBAZA.PL" Sp. z o.o. Technologie WEB, eDB& eCommerce tel. (+4832) 7186081 fax. (+4832) 7003289 email: biuro@techbaza.pl web: http://www.techbaza.pl web: partner.techbaza.pl web: ekspert.techbaza.pl
Le 25/04/2011 12:44, Piotr Czekalski a écrit : > [...] > First of all - Happy Easter to all of the readers! > > I've got a question related to the reconnection procedure, when > connection lost. > It is quite easy to do in the main PgAdmin window, but how do I > reconnect to the same database when operating within SQL Query window? > When connection lost, I do can connect to the other databases using > combobox located on the toolbar, but can't reconnect to the one that was > used before connection was lost. > > Steps to reproduce: > 1. Configure connections at least to the two databases, connect to the > first of them. > 2. Open SQL Query window, write and execute some query. > 3. Disconnect and reconnet your network connection. > 4. Your connection is dropped - try to reconnect -> impossible, but you > still can connect to the other database than in point 1. > Yeah, if the selected parameters are the same than an old connection, then we use the old connection, so that we don't get too many connections to the same handle (host/database/user). We should probably first check if the connection is still available and reconnect otherwise. -- Guillaumehttp://www.postgresql.frhttp://dalibo.com
Hi, On 04/26/2011 12:46 PM, Piotr Czekalski wrote: > [...] > I'd would appreciate such feature, because working over GSM modem, which > is common to the administrators novadays (I think) is a nightmare ;-). > Got a patch that works. See the attachment. If the query fails, it checks if it's because of a bad connection. If connection is bad, it resets it, and executes once again the query. If it still fails, you have the usual error message. If it succeeds, you won't even notice that it had to reset the connection. I don't see any issue with this patch, but would like others to get a look. It's wxThread and that kind of stuff is not really my thing (threading... eeks). And one more question, we're really early in beta stage. Usually, it would have to wait a few months to get commited in next dev cycle. But it is so early in this stage (actually, beta 1 is not even announced yet), and it would be a so much welcomed patch that I think it could be commited for this release (ie, 1.14). Any opinions, objections, ideas? -- Guillaume http://www.postgresql.fr http://dalibo.com
Attachment
On Sun, May 1, 2011 at 4:32 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Hi, > > On 04/26/2011 12:46 PM, Piotr Czekalski wrote: >> [...] >> I'd would appreciate such feature, because working over GSM modem, which >> is common to the administrators novadays (I think) is a nightmare ;-). >> > > Got a patch that works. See the attachment. If the query fails, it > checks if it's because of a bad connection. If connection is bad, it > resets it, and executes once again the query. If it still fails, you > have the usual error message. If it succeeds, you won't even notice that > it had to reset the connection. > > I don't see any issue with this patch, but would like others to get a > look. It's wxThread and that kind of stuff is not really my thing > (threading... eeks). > > And one more question, we're really early in beta stage. Usually, it > would have to wait a few months to get commited in next dev cycle. But > it is so early in this stage (actually, beta 1 is not even announced > yet), and it would be a so much welcomed patch that I think it could be > commited for this release (ie, 1.14). > > Any opinions, objections, ideas? You cannot just reconnect silently in a patch like this - the user may have created temp tables or otherwise modified the connection-specific environment before the connection was lost. Blindly reconnecting and then executing the query could have disastrous effects. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 05/02/2011 10:20 AM, Dave Page wrote: > On Sun, May 1, 2011 at 4:32 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Hi, >> >> On 04/26/2011 12:46 PM, Piotr Czekalski wrote: >>> [...] >>> I'd would appreciate such feature, because working over GSM modem, which >>> is common to the administrators novadays (I think) is a nightmare ;-). >>> >> >> Got a patch that works. See the attachment. If the query fails, it >> checks if it's because of a bad connection. If connection is bad, it >> resets it, and executes once again the query. If it still fails, you >> have the usual error message. If it succeeds, you won't even notice that >> it had to reset the connection. >> >> I don't see any issue with this patch, but would like others to get a >> look. It's wxThread and that kind of stuff is not really my thing >> (threading... eeks). >> >> And one more question, we're really early in beta stage. Usually, it >> would have to wait a few months to get commited in next dev cycle. But >> it is so early in this stage (actually, beta 1 is not even announced >> yet), and it would be a so much welcomed patch that I think it could be >> commited for this release (ie, 1.14). >> >> Any opinions, objections, ideas? > > You cannot just reconnect silently in a patch like this - the user may > have created temp tables or otherwise modified the connection-specific > environment before the connection was lost. Blindly reconnecting and > then executing the query could have disastrous effects. > Indeed, you're right. I knew I forgot something important with this patch :) Too bad, because I really liked the silent reconnection. Well, I suppose I'll have to change this to make it verbose. -- Guillaume http://www.postgresql.fr http://dalibo.com
Actually I don't mind if it is silent or verbose, any of them works for me, but Dave seems to be right for particular cases, so I vote for verbose solution ;-). Thanks in advance for your help, Piotr > Indeed, you're right. I knew I forgot something important with this patch :) > > Too bad, because I really liked the silent reconnection. Well, I suppose > I'll have to change this to make it verbose. > > -- -------------------------------------------------------------- "TECHBAZA.PL" Sp. z o.o. Technologie WEB, eDB& eCommerce tel. (+4832) 7186081 fax. (+4832) 7003289 email: biuro@techbaza.pl web: http://www.techbaza.pl web: partner.techbaza.pl web: ekspert.techbaza.pl
On 05/02/2011 10:09 PM, Guillaume Lelarge wrote: > On 05/02/2011 10:20 AM, Dave Page wrote: >> On Sun, May 1, 2011 at 4:32 PM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >>> Hi, >>> >>> On 04/26/2011 12:46 PM, Piotr Czekalski wrote: >>>> [...] >>>> I'd would appreciate such feature, because working over GSM modem, which >>>> is common to the administrators novadays (I think) is a nightmare ;-). >>>> >>> >>> Got a patch that works. See the attachment. If the query fails, it >>> checks if it's because of a bad connection. If connection is bad, it >>> resets it, and executes once again the query. If it still fails, you >>> have the usual error message. If it succeeds, you won't even notice that >>> it had to reset the connection. >>> >>> I don't see any issue with this patch, but would like others to get a >>> look. It's wxThread and that kind of stuff is not really my thing >>> (threading... eeks). >>> >>> And one more question, we're really early in beta stage. Usually, it >>> would have to wait a few months to get commited in next dev cycle. But >>> it is so early in this stage (actually, beta 1 is not even announced >>> yet), and it would be a so much welcomed patch that I think it could be >>> commited for this release (ie, 1.14). >>> >>> Any opinions, objections, ideas? >> >> You cannot just reconnect silently in a patch like this - the user may >> have created temp tables or otherwise modified the connection-specific >> environment before the connection was lost. Blindly reconnecting and >> then executing the query could have disastrous effects. >> > > Indeed, you're right. I knew I forgot something important with this patch :) > > Too bad, because I really liked the silent reconnection. Well, I suppose > I'll have to change this to make it verbose. > Something more like this, then? -- Guillaume http://www.postgresql.fr http://dalibo.com
Attachment
On Mon, May 2, 2011 at 10:37 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> On 05/02/2011 10:09 PM, Guillaume Lelarge wrote:
>> On 05/02/2011 10:20 AM, Dave Page wrote:
>>> On Sun, May 1, 2011 at 4:32 PM, Guillaume Lelarge
>>> <guillaume@lelarge.info> wrote:
>>>> Hi,
>>>>
>>>> On 04/26/2011 12:46 PM, Piotr Czekalski wrote:
>>>>> [...]
>>>>> I'd would appreciate such feature, because working over GSM modem, which
>>>>> is common to the administrators novadays (I think) is a nightmare ;-).
>>>>>
>>>>
>>>> Got a patch that works. See the attachment. If the query fails, it
>>>> checks if it's because of a bad connection. If connection is bad, it
>>>> resets it, and executes once again the query. If it still fails, you
>>>> have the usual error message. If it succeeds, you won't even notice that
>>>> it had to reset the connection.
>>>>
>>>> I don't see any issue with this patch, but would like others to get a
>>>> look. It's wxThread and that kind of stuff is not really my thing
>>>> (threading... eeks).
>>>>
>>>> And one more question, we're really early in beta stage. Usually, it
>>>> would have to wait a few months to get commited in next dev cycle. But
>>>> it is so early in this stage (actually, beta 1 is not even announced
>>>> yet), and it would be a so much welcomed patch that I think it could be
>>>> commited for this release (ie, 1.14).
>>>>
>>>> Any opinions, objections, ideas?
>>>
>>> You cannot just reconnect silently in a patch like this - the user may
>>> have created temp tables or otherwise modified the connection-specific
>>> environment before the connection was lost. Blindly reconnecting and
>>> then executing the query could have disastrous effects.
>>>
>>
>> Indeed, you're right. I knew I forgot something important with this patch :)
>>
>> Too bad, because I really liked the silent reconnection. Well, I suppose
>> I'll have to change this to make it verbose.
>>
>
> Something more like this, then?
That doesn't look entirely objectionable :-p
Couple of wording tweaks though - first, why not reuse the existing
reconnection messages:
wxMessageDialog dlg(this, _("Do you want to attempt to reconnect to
the database?"),
wxString::Format(_("Connection to database %s lost."),
db->GetName().c_str()),
wxICON_EXCLAMATION | wxYES_NO | wxYES_DEFAULT);
Second:
"Connection resetted." -> "Connection reset."
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 05/03/2011 11:09 AM, Dave Page wrote:
> On Mon, May 2, 2011 at 10:37 PM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
>> On 05/02/2011 10:09 PM, Guillaume Lelarge wrote:
>>> On 05/02/2011 10:20 AM, Dave Page wrote:
>>>> On Sun, May 1, 2011 at 4:32 PM, Guillaume Lelarge
>>>> <guillaume@lelarge.info> wrote:
>>>>> Hi,
>>>>>
>>>>> On 04/26/2011 12:46 PM, Piotr Czekalski wrote:
>>>>>> [...]
>>>>>> I'd would appreciate such feature, because working over GSM modem, which
>>>>>> is common to the administrators novadays (I think) is a nightmare ;-).
>>>>>>
>>>>>
>>>>> Got a patch that works. See the attachment. If the query fails, it
>>>>> checks if it's because of a bad connection. If connection is bad, it
>>>>> resets it, and executes once again the query. If it still fails, you
>>>>> have the usual error message. If it succeeds, you won't even notice that
>>>>> it had to reset the connection.
>>>>>
>>>>> I don't see any issue with this patch, but would like others to get a
>>>>> look. It's wxThread and that kind of stuff is not really my thing
>>>>> (threading... eeks).
>>>>>
>>>>> And one more question, we're really early in beta stage. Usually, it
>>>>> would have to wait a few months to get commited in next dev cycle. But
>>>>> it is so early in this stage (actually, beta 1 is not even announced
>>>>> yet), and it would be a so much welcomed patch that I think it could be
>>>>> commited for this release (ie, 1.14).
>>>>>
>>>>> Any opinions, objections, ideas?
>>>>
>>>> You cannot just reconnect silently in a patch like this - the user may
>>>> have created temp tables or otherwise modified the connection-specific
>>>> environment before the connection was lost. Blindly reconnecting and
>>>> then executing the query could have disastrous effects.
>>>>
>>>
>>> Indeed, you're right. I knew I forgot something important with this patch :)
>>>
>>> Too bad, because I really liked the silent reconnection. Well, I suppose
>>> I'll have to change this to make it verbose.
>>>
>>
>> Something more like this, then?
>
> That doesn't look entirely objectionable :-p
>
> Couple of wording tweaks though - first, why not reuse the existing
> reconnection messages:
>
> wxMessageDialog dlg(this, _("Do you want to attempt to reconnect to
> the database?"),
> wxString::Format(_("Connection to database %s lost."),
> db->GetName().c_str()),
> wxICON_EXCLAMATION | wxYES_NO | wxYES_DEFAULT);
>
> Second:
>
> "Connection resetted." -> "Connection reset."
>
OK, will do.
And about the fact that we're already past beta 1?
--
Guillaume
http://www.postgresql.fr
http://dalibo.com
On Tue, May 3, 2011 at 11:15 AM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> On 05/03/2011 11:09 AM, Dave Page wrote:
>> On Mon, May 2, 2011 at 10:37 PM, Guillaume Lelarge
>> <guillaume@lelarge.info> wrote:
>>> On 05/02/2011 10:09 PM, Guillaume Lelarge wrote:
>>>> On 05/02/2011 10:20 AM, Dave Page wrote:
>>>>> On Sun, May 1, 2011 at 4:32 PM, Guillaume Lelarge
>>>>> <guillaume@lelarge.info> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 04/26/2011 12:46 PM, Piotr Czekalski wrote:
>>>>>>> [...]
>>>>>>> I'd would appreciate such feature, because working over GSM modem, which
>>>>>>> is common to the administrators novadays (I think) is a nightmare ;-).
>>>>>>>
>>>>>>
>>>>>> Got a patch that works. See the attachment. If the query fails, it
>>>>>> checks if it's because of a bad connection. If connection is bad, it
>>>>>> resets it, and executes once again the query. If it still fails, you
>>>>>> have the usual error message. If it succeeds, you won't even notice that
>>>>>> it had to reset the connection.
>>>>>>
>>>>>> I don't see any issue with this patch, but would like others to get a
>>>>>> look. It's wxThread and that kind of stuff is not really my thing
>>>>>> (threading... eeks).
>>>>>>
>>>>>> And one more question, we're really early in beta stage. Usually, it
>>>>>> would have to wait a few months to get commited in next dev cycle. But
>>>>>> it is so early in this stage (actually, beta 1 is not even announced
>>>>>> yet), and it would be a so much welcomed patch that I think it could be
>>>>>> commited for this release (ie, 1.14).
>>>>>>
>>>>>> Any opinions, objections, ideas?
>>>>>
>>>>> You cannot just reconnect silently in a patch like this - the user may
>>>>> have created temp tables or otherwise modified the connection-specific
>>>>> environment before the connection was lost. Blindly reconnecting and
>>>>> then executing the query could have disastrous effects.
>>>>>
>>>>
>>>> Indeed, you're right. I knew I forgot something important with this patch :)
>>>>
>>>> Too bad, because I really liked the silent reconnection. Well, I suppose
>>>> I'll have to change this to make it verbose.
>>>>
>>>
>>> Something more like this, then?
>>
>> That doesn't look entirely objectionable :-p
>>
>> Couple of wording tweaks though - first, why not reuse the existing
>> reconnection messages:
>>
>> wxMessageDialog dlg(this, _("Do you want to attempt to reconnect to
>> the database?"),
>> wxString::Format(_("Connection to database %s lost."),
>> db->GetName().c_str()),
>> wxICON_EXCLAMATION | wxYES_NO | wxYES_DEFAULT);
>>
>> Second:
>>
>> "Connection resetted." -> "Connection reset."
>>
>
> OK, will do.
>
> And about the fact that we're already past beta 1?
I'd call it a bug. There is no sane way to re-establish that connection.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 05/03/2011 12:17 PM, Dave Page wrote:
> On Tue, May 3, 2011 at 11:15 AM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
>> On 05/03/2011 11:09 AM, Dave Page wrote:
>>> On Mon, May 2, 2011 at 10:37 PM, Guillaume Lelarge
>>> <guillaume@lelarge.info> wrote:
>>>> On 05/02/2011 10:09 PM, Guillaume Lelarge wrote:
>>>>> On 05/02/2011 10:20 AM, Dave Page wrote:
>>>>>> On Sun, May 1, 2011 at 4:32 PM, Guillaume Lelarge
>>>>>> <guillaume@lelarge.info> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 04/26/2011 12:46 PM, Piotr Czekalski wrote:
>>>>>>>> [...]
>>>>>>>> I'd would appreciate such feature, because working over GSM modem, which
>>>>>>>> is common to the administrators novadays (I think) is a nightmare ;-).
>>>>>>>>
>>>>>>>
>>>>>>> Got a patch that works. See the attachment. If the query fails, it
>>>>>>> checks if it's because of a bad connection. If connection is bad, it
>>>>>>> resets it, and executes once again the query. If it still fails, you
>>>>>>> have the usual error message. If it succeeds, you won't even notice that
>>>>>>> it had to reset the connection.
>>>>>>>
>>>>>>> I don't see any issue with this patch, but would like others to get a
>>>>>>> look. It's wxThread and that kind of stuff is not really my thing
>>>>>>> (threading... eeks).
>>>>>>>
>>>>>>> And one more question, we're really early in beta stage. Usually, it
>>>>>>> would have to wait a few months to get commited in next dev cycle. But
>>>>>>> it is so early in this stage (actually, beta 1 is not even announced
>>>>>>> yet), and it would be a so much welcomed patch that I think it could be
>>>>>>> commited for this release (ie, 1.14).
>>>>>>>
>>>>>>> Any opinions, objections, ideas?
>>>>>>
>>>>>> You cannot just reconnect silently in a patch like this - the user may
>>>>>> have created temp tables or otherwise modified the connection-specific
>>>>>> environment before the connection was lost. Blindly reconnecting and
>>>>>> then executing the query could have disastrous effects.
>>>>>>
>>>>>
>>>>> Indeed, you're right. I knew I forgot something important with this patch :)
>>>>>
>>>>> Too bad, because I really liked the silent reconnection. Well, I suppose
>>>>> I'll have to change this to make it verbose.
>>>>>
>>>>
>>>> Something more like this, then?
>>>
>>> That doesn't look entirely objectionable :-p
>>>
>>> Couple of wording tweaks though - first, why not reuse the existing
>>> reconnection messages:
>>>
>>> wxMessageDialog dlg(this, _("Do you want to attempt to reconnect to
>>> the database?"),
>>> wxString::Format(_("Connection to database %s lost."),
>>> db->GetName().c_str()),
>>> wxICON_EXCLAMATION | wxYES_NO | wxYES_DEFAULT);
>>>
>>> Second:
>>>
>>> "Connection resetted." -> "Connection reset."
>>>
>>
>> OK, will do.
>>
>> And about the fact that we're already past beta 1?
>
> I'd call it a bug. There is no sane way to re-establish that connection.
>
>
OK, done and pushed. Thanks.
--
Guillaume
http://www.postgresql.fr
http://dalibo.com