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

Started by David E. Wheelerover 15 years ago4 messagesbugs
Jump to latest
#1David E. Wheeler
david@kineticode.com

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.

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: David E. Wheeler (#1)
Re: BUG #5616: psql Doesn't Change Log files on \c

"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

In reply to: Tom Lane (#2)
Re: BUG #5616: psql Doesn't Change Log files on \c

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

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: hubert depesz lubaczewski (#3)
Re: BUG #5616: psql Doesn't Change Log files on \c

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