Re: psql doesn't reuse -p after backend fail

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: depesz(at)depesz(dot)com, pgsql-bugs(at)postgresql(dot)org
Subject: Re: psql doesn't reuse -p after backend fail
Date: 2011-09-05 18:44:40
Message-ID: 4E651898.5030502@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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...

Stefan

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2011-09-05 20:19:48 Re: BUG #5932: CLUSTER doesn't update n_dead_tup
Previous Message Tom Lane 2011-09-05 18:27:23 Re: psql doesn't reuse -p after backend fail