Обсуждение: BUG #5616: psql Doesn't Change Log files on \c

The following bug has been logged online:

Bug reference:      5616
Logged by:          David E. Wheeler
Email address:      david@kineticode.com
PostgreSQL version: 8.4
Operating system:   Mac OS X 10.6.4
Description:        psql Doesn't Change Log files on \c
Details:

I have this in my .psqlrc:

    \set HISTFILE ~/.psql_history- :DBNAME

This is great, except when I change databases in a session:

    % psql foo
    foo % \c bar
    You are now connected to database "bar".
    SELECT true;

The last statement will be logged to ~/.psql_history-foo when it should go
to ~/.psql_history-bar.

"David E. Wheeler" <david@kineticode.com> writes:
> I have this in my .psqlrc:
>     \set HISTFILE ~/.psql_history- :DBNAME
> This is great, except when I change databases in a session:

>     % psql foo
>     foo % \c bar
>     You are now connected to database "bar".
>     SELECT true;

> The last statement will be logged to ~/.psql_history-foo when it should go
> to ~/.psql_history-bar.

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

            regards, tom lane

On Thu, Aug 12, 2010 at 06:33:13PM -0400, Tom Lane wrote:
> "David E. Wheeler" <david@kineticode.com> writes:
> > I have this in my .psqlrc:
> >     \set HISTFILE ~/.psql_history- :DBNAME
> > This is great, except when I change databases in a session:
>
> >     % psql foo
> >     foo % \c bar
> >     You are now connected to database "bar".
> >     SELECT true;
>
> > The last statement will be logged to ~/.psql_history-foo when it should go
> > to ~/.psql_history-bar.
>
> 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.

depesz

--
Linkedin: http://www.linkedin.com/in/depesz  /  blog: http://www.depesz.com/
jid/gtalk: depesz@depesz.com / aim:depeszhdl / skype:depesz_hdl / gg:6749007

hubert depesz lubaczewski <depesz@depesz.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