guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Broken pipe errors using guile-pg with guile 1.8


From: Greg Troxel
Subject: Re: Broken pipe errors using guile-pg with guile 1.8
Date: Mon, 23 Feb 2009 18:44:51 -0500
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.3 (berkeley-unix)

Sebastian Tennant <address@hidden> writes:

> Quoth Greg Troxel <address@hidden>:
>> Sebastian Tennant <address@hidden> writes:
>>
>> By 0.16, I think you mean ttn's version of Ian Grant's abandoned 0.07 or
>> so.
> On closer inspection, it probably is the version you're referring to as
> ttn is the author of all the supplementary postgres-*.scm files included
> in the package.

Yes, sounds like it.  I am only aware of three things with names like this

  guile-pg 0.07ish by Ian
  guile-pg ?-0.30ish, ttn-enhanced version of Ian's code
  pg-guile - BSD licensed, not maintained, totally different

> I know ttn's guile-pg (available from gnuvola.org) is much more
> up-to-date but unfortunately it's only compatible with his guile-1.4.x
> branch.

Not true - it works with 1.6

>>> All my calls to pg-connectdb are let bound so database connections are
>>> (supposed to be) closed after every query.
>>
>> I am not sure that gc will run as soon as you drop the reference, 
>
> So you agree with my diagnosis?  Are there some arbitrary limits to how
> many database connections (iniated by pg-connectdb) can remain open at
> once?  There's no mention of that in the manual.

I'm sure there are such limits, and suspect that most of those competent
to document them would have the same reaction I did :-)

>> so you might want to force gc, or better yet explicitly close the db
>> object.
>
> From the manual accompanying my version:
>
>    "`Guile-pg' connections are closed when Guile's garbage collector
>  collects the discarded object.  This only happens when the connection
>  itself and all of the results of `pg-exec' are unreachable.  So to
>  close the connection we just rebind the results from that connection
>  and the connection symbol itself:
>
>       guile> (define result '())
>       guile> (define test '())
>
>     Typically though the result and connection variables will be `let'
>  bindings so the connection will usually be closed soon after the body
>  of the `let' returns."          ^^^^^^^           ^^^^

Wow, that is funky.  I would expect an explicit pg-close that sets the
connection to a dead state and cleans up the state on the pg side.

> I don't like the sound of 'usually' and 'soon' now that I read this
> again in the light of the problems I'm experiencing.  Here's one of
> scores of database procedures I've written for this particular web-app:
>
>  (define (username-in-use? username)
>    (let* ((dbconn (pg-connectdb "dbname=xxxx"))
>           (q (pg-exec dbconn (sa "SELECT username FROM joblist "
>                                  "WHERE username='" username "';"))))
>      (> (pg-ntuples q) 0)))
>
> I can't see how rebinding 'dbconn' and 'q' within this let form is going
> to make any difference (plus I need a boolean return value, not
> #unspecified as returned by set!).  Is this what you mean by "explicitly
> closing the db object"?

No, I mean to call a close function so that the scheme object still
exists, but the PG object behind it has been closed.  In 0.37, there is
pg-finish.

> Forcing gc after each procedure call which initiates a database
> connection is a possible course of action.

By which I mean '(gc)' in your code.

>> You could add a debug printf in the free/close function to check this
>> hypothesis, 
>
> As there are no free/close functions (everything is let bound) could you
> be more specific as to how I could debug the cause of these broken
> pipes?

Edit the source to guile-pg and find the function that is called when gc
finds the smob.  That in 0.37 is called xc_free, and it has GC_PRINT.

>>> P.S. Perhaps upgrading guile-pg is the first thing I should try? IIRC
>>>      there's a more recent pkgsrc version (which is guile 1.8
>>>      comaptible) somewhere... hunting for it now.
>>
>> I suspect a day or so of work would suffice to make the most recent
>> guile-pg work with 1.8.  If you do it definitely post patches.
>
> For C programmers perhaps, but not lowly scripters like myself.
>
> Out of interest which do you consider the most recent guile-pg (ttn's or
> some other, available from where)?

Definitely 0.37, from http://www.gnuvola.org/software/guile-pg/

If you are not up to writing C code, then my advice is to change your
usage patterns to use very few database connection objects.  They can be
reused for each query, instead of being created and discarded all the
time.

See test/large.scm and test/meta.scm in 0.37; they both use pg-finish.

Attachment: pgpYvDxISkDue.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]