On 09/05/2011 08:27 PM, Tom Lane wrote:
> hubert depesz lubaczewski <depesz(at)depesz(dot)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...
In response to
pgsql-bugs by date
|Next:||From: Bruce Momjian||Date: 2011-09-05 20:19:48|
|Subject: Re: BUG #5932: CLUSTER doesn't update n_dead_tup|
|Previous:||From: Tom Lane||Date: 2011-09-05 18:27:23|
|Subject: Re: psql doesn't reuse -p after backend fail |