Re: psql doesn't reuse -p after backend fail - Mailing list pgsql-bugs

From Stefan Kaltenbrunner
Subject Re: psql doesn't reuse -p after backend fail
Date
Msg-id 4E651898.5030502@kaltenbrunner.cc
Whole thread Raw
In response to Re: psql doesn't reuse -p after backend fail  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On 09/05/2011 08:27 PM, Tom Lane wrote:
> hubert depesz lubaczewski <depesz@depesz.com> writes:
>> ran psql with specyfying port:
>> psql -p 4329 -U postgres -d some_database
>
>> then I run query which breaks backend:
>
>> =# select * from categories limit 1;
>> The connection to the server was lost. Attempting reset: Failed.
>> !>
>
>> When I'll try to re-issue \c some_database now, I got:
>
>> !> \c some_database
>> could not connect to server: No such file or directory
>>         Is the server running locally and accepting
>>         connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
>> !>
>
> It's not just the port, it's all the connection parameters ---
> do_connect relies on the PGconn object to remember those, and in this
> case there no longer is a PGconn object.
>
> We could have psql keep that information separately, but I'm not sure
> it's really worth the trouble.

hmm I can see this as potentially very dangerous, just picture what
might happen if you actually get a connection because there is another
instance actually running on the default port (say 5432 is production
and 4329 is development) and you end up issuing the wrong commands.
If we provide "automatic reconnect" we should rather do that correctly
or not at all...


Stefan

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: psql doesn't reuse -p after backend fail
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #5932: CLUSTER doesn't update n_dead_tup