Hi,
I usually use host-based authentication with ident to connect to PostgreSQL from trusted machines, so I've been specifying a password of NIL for a long time. However, when passwordless authentication fails and NIL is given as a password, POSTMODERN:CONNECT will behave erratically.
In my case, the symptoms are:
* SBCL (Debian 1:1.0.18.0-2) RAM usage balloons to hundreds of megabytes.
* I get this condition printed, along with a tag-along (obscure and what I assume to be) object, for the heck of it:
---8<---8<--- * (postmodern:connect "piranha" "piranha" nil "localhost") debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" RUNNING {1002669C31}>: The value NIL is not of type (MOD 1152921504606846975).
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level.
(SB-KERNEL:UB32-BASH-COPY "piranha" 0 "" NIL 7)[:EXTERNAL] --->8--->8---
That's invoking SBCL on the command-line. When I use SLIME:
* SBCL, like a gas, expands to fill all available space (e.g. ~1.8GiB before I ran out of RAM+swap and rebooted the virtual machine).
* During this time, nothing ever comes back to emacs.
* If I do a SLIME interrupt before the system completely dies, emacs takes a while to do anything, then enters the emacs (not SLIME!) debugger, and informs me that the "variable binding depth exceeds max-specpdl-size" at every available opportunity until I restart emacs.
It turns out bad things happen when you optimize for safety 0. Making this change:
diff -x'*~' -urN postmodern-1.16/cl-postgres/package.lisp postmodern-1.16-no_opt/cl-postgres/package.lisp --- postmodern-1.16/cl-postgres/package.lisp 2010-04-02 04:23:24.000000000 -0700 +++ postmodern-1.16-no_opt/cl-postgres/package.lisp 2010-04-06 06:00:47.000000000 -0700 @@ -83,5 +83,5 @@ (eval-when (:compile-toplevel :load-toplevel :execute) ;; Optimization settings (only used by functions that need it). (defparameter *optimize* - '(optimize (speed 3) (safety 0) (space 1) (debug 1) + '(optimize (speed 3) (space 1) (debug 1) (compilation-speed 0))))
yields a much more sensible, instantaneous, and non-ballooning:
The value NIL is not of type STRING. [Condition of type TYPE-ERROR]
Of course, bad things also happen when you pass objects of the wrong type to a function. (It just never sat well with me to pass a string password when no password was needed; NIL seemed to make much more sense, and it worked...)
I've attached a patch to:
* Check the types of arguments given to CL-POSTGRES:OPEN-DATABASE.
* Update the HTML documentation to describe the expected types of arguments to CL-POSTGRES:OPEN-DATABASE and POSTMODERN:CONNECT.
* Update the documentation strings for the above two functions to contain the same content as their descriptions in the HTML documentation.
I also humbly suggest not optimizing for safety 0. One of the big reasons I use CL, and not something like C, is because I value safety: when one thing breaks, that breakage is self-contained and can be tracked down due to conditions. I don't want my Lisp process to go down like the Hindenburg when one little thing goes wrong.
Thanks for your time,
Hello J.P.,
I usually use host-based authentication with ident to connect to PostgreSQL from trusted machines, so I've been specifying a password of NIL for a long time. However, when passwordless authentication fails and NIL is given as a password, POSTMODERN:CONNECT will behave erratically.
Hm, yes, I really shouldn't be passing un-type-checked parameters to functions compiled at (safety 0).
I've applied a patch that adds your check-type forms, and made a change to allow NIL as password (the authentication code will raise an error when the server demands a password and none was given).
I did not apply the full doc changes you submitted. I can see the value of thoroughness, but I think telling people that a usename should be a string etc. seems a superfluous (especially when it has to be done four times -- two docstrings and two html documents)
I also humbly suggest not optimizing for safety 0.
I see your point, yet when I profiled postmodern (back in 2007, on SBCL, not sure if this still holds) the speed difference between (safety 1) and (safety 0) was very significant (25% range, if I remember correctly). Memory safety in a chaotically-typed language like CL means a *lot* of checks. Feel free to run some benchmarks again, and see what you get (my benchmark consisted of inserting a lot of data, and making queries that returned huge result sets).
Best, Marijn
On Tue, Apr 06, 2010 at 07:39:38PM +0200, Marijn Haverbeke wrote:
I usually use host-based authentication with ident to connect to PostgreSQL from trusted machines, so I've been specifying a password of NIL for a long time. However, when passwordless authentication fails and NIL is given as a password, POSTMODERN:CONNECT will behave erratically.
Hm, yes, I really shouldn't be passing un-type-checked parameters to functions compiled at (safety 0).
I've applied a patch that adds your check-type forms, and made a change to allow NIL as password (the authentication code will raise an error when the server demands a password and none was given).
Thanks! The pedantic doc changes I attached don't really fit in with the level of detail in the Postmodern HTML documentation (and especially the docstrings), so I understand why you'd want to leave those out.
I also humbly suggest not optimizing for safety 0.
I see your point, yet when I profiled postmodern (back in 2007, on SBCL, not sure if this still holds) the speed difference between (safety 1) and (safety 0) was very significant (25% range, if I remember correctly). Memory safety in a chaotically-typed language like CL means a *lot* of checks. Feel free to run some benchmarks again, and see what you get (my benchmark consisted of inserting a lot of data, and making queries that returned huge result sets).
Fair enough. Thanks,
postmodern-devel@common-lisp.net
-
J.P. Larocque -
Marijn Haverbeke