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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: depesz(at)depesz(dot)com, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: psql doesn't reuse -p after backend fail
Date: 2011-09-15 03:52:50
Message-ID: CA+TgmoZ10jzgLsEaN=80Na9_orTG=8F2u23gaqw9xjYmRq736w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Sep 8, 2011 at 5:09 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On tis, 2011-09-06 at 17:12 +0200, hubert depesz lubaczewski wrote:
>> On Mon, Sep 05, 2011 at 02:27:23PM -0400, Tom Lane wrote:
>> > 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.
>>
>> well, I think it's definitely worth the trouble. If I had datbaase
>> standing at 5432, it would connect to it, and then I could mistakenly
>> ran commands to wrong database.
>> this is clearly not a good thing.
>
> Perhaps just prevent \connect without argument if the information is no
> longer available.

I think it'd be worth actually having psql maintain the information
separately from the PGconn... but if nobody feels motivated to go do
that, doing at least this much would remove the foot-gun. So +1 for
that.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Eduardo Piombino 2011-09-15 03:55:44 BUG #6207: fali to get lock on parent table after two consecutive updates to the same row in child table
Previous Message Robert Haas 2011-09-15 03:45:52 Re: Dropped index on table preventing rule creation