Re: BUG #5616: psql Doesn't Change Log files on \c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: depesz(at)depesz(dot)com
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5616: psql Doesn't Change Log files on \c
Date: 2010-08-13 13:34:33
Message-ID: 22158.1281706473@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

hubert depesz lubaczewski <depesz(at)depesz(dot)com> writes:
> On Thu, Aug 12, 2010 at 06:33:13PM -0400, Tom Lane wrote:
>> I don't think this is a bug. The history file is read at psql startup
>> and written out (to the same file name) at exit. Those operations are
>> quite expensive, so it would be insane to do them after every backslash
>> command on the off chance that somebody was expecting to have changed
>> the effective name of the history file. (Aside from the cost, this
>> would greatly increase the race condition hazards from concurrent psql
>> sessions trying to write the file at the same time.)

> I think it would be enough to track previous and current database name,
> and re-do the history code on change.

That would only satisfy people who were doing exactly what David is
doing. There could be anything in the definition of HISTFILE. Username
is one obvious possibility, but there are others.

In any case I don't think you realize what "redoing the history code"
would entail. It would mean that you lose the session history up to
that point, replacing it with whatever command history was recent
according to the other history file. I doubt that that's desirable,
and it's certainly hugely incompatible with psql's traditional history
behavior.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2010-08-13 13:59:17 Re: BUG #5617: pg_restore behaves unexpectedly on 'invalid' command line
Previous Message Heikki Linnakangas 2010-08-13 12:01:23 Assertion failure from plan cache invalidation