From kubo at jiubao.org  Tue Aug 26 21:56:40 2008
From: kubo at jiubao.org (KUBO Takehiro)
Date: Wed, 27 Aug 2008 10:56:40 +0900
Subject: [ruby-dbi-users] dbd_pg and deallocating prepared statements
Message-ID: <5d847bcd0808261856p5d77328chf53c14db2edbf3ad@mail.gmail.com>

Pardon me if I'm not correct. I have been interested in how various
DBMSs implement prepared statements. But I have not used postgresql
for 9 years.

dbd_pg uses prepared statements for all queries. But who deallocate the
prepared statements? "@stmt.clear if @stmt" doesn't do it.
IMO, if a ruby process uses one database session for all SQL statements
and issues them periodically, server side (postmaster) memory will be
increased as time goes.

See: http://www.postgresql.org/docs/8.3/static/libpq-exec.html#AEN30965
     http://www.postgresql.org/docs/8.3/static/sql-deallocate.html

From erik at hollensbe.org  Wed Aug 27 03:43:50 2008
From: erik at hollensbe.org (Erik Hollensbe)
Date: Wed, 27 Aug 2008 00:43:50 -0700
Subject: [ruby-dbi-users] dbd_pg and deallocating prepared statements
In-Reply-To: <5d847bcd0808261856p5d77328chf53c14db2edbf3ad@mail.gmail.com>
References: <5d847bcd0808261856p5d77328chf53c14db2edbf3ad@mail.gmail.com>
Message-ID: <200808270043.50805.erik@hollensbe.org>

On Tuesday 26 August 2008 18:56:40 KUBO Takehiro wrote:
> Pardon me if I'm not correct. I have been interested in how various
> DBMSs implement prepared statements. But I have not used postgresql
> for 9 years.
>
> dbd_pg uses prepared statements for all queries. But who deallocate the
> prepared statements? "@stmt.clear if @stmt" doesn't do it.
> IMO, if a ruby process uses one database session for all SQL statements
> and issues them periodically, server side (postmaster) memory will be
> increased as time goes.

Correct. I explored this a bit when that patch was provided and I couldn't 
find anything in the pg driver that allowed me to cleanly close statements, 
and (inappropriately) made the assumption that they would at some point be 
collected.

I will try and get a fix out this week. Thanks.

-Erik

From erik at hollensbe.org  Fri Aug 29 22:17:39 2008
From: erik at hollensbe.org (Erik Hollensbe)
Date: Fri, 29 Aug 2008 19:17:39 -0700
Subject: [ruby-dbi-users] 0.4.0 postmortem and RFC
Message-ID: <200808291917.39623.erik@hollensbe.org>

First off, sorry this is so long. Second, if you are experiencing the Pg DBD 
problem KUBO Takehiro mentioned earlier or the MySQL problems discovered by 
Pistos, expect a resolution in the next day or two. 

There are a couple of things that need to be addressed before we can continue 
with 0.6.0. Anyone who's compared 0.2.0 (which is really just 0.1.1 with some 
bugfixes) to 0.4.0 knows that I took a very large, fast moving hatchet to a 
lot of things in the existing architecture and added a few things that aren't 
backwards compatible.

0.4.0 took way too long to get to rubyforge and I'm the only one to blame for 
that.

I certainly am aware that DBI has plenty of unresolved issues and the goal is 
to resolve these instead of just acknowledging they exist and complaining 
about them. If you have comments on 0.4.0 flaws, or what you'd like to see in 
0.6.0, please attach them to this thread or in the tracker. I'm not expecting 
patches for these issues, just information on them and any opinions that come 
with them. Please keep our goals in mind, they are explained at http://ruby-
dbi.rubyforge.org/

Feel free to open the flood gates, the point here is to build a better tool, 
not beat chests. It would be nice to keep the personal attacks to a minimum. 
Brainstorm your eyes out, nothing is sacred for this exercise.

Anyways, here is a terse (yes, really) list of things both proposed to me and 
thought of by me that are on the possible changes list:

- Proxy and Trace fixed and working
- DBI.connect should have consistent arguments, should not rely on DBD 
interaction at all. This mainly involves the parsing of "enhanced" connect 
strings and arguments
- provide a well-defined spec for the above; how db-specific parameters are 
defined and how parameters interact with the system in general.
- gem interaction with methods like available_drivers
- outbound binds (this was planned for 0.4.0, scrapped for time)
- enforcing API for columninfo, etc (DBDs must return these fields in these 
cases)
- test system that can test DBDs independently
- better thread support
- axe case-insensitivity for driver names in connect strings; this is the 
cause of a lot of error-prone code in the core.
- a more complete SQL parser for DBDs that don't provide, or want to use, 
native binding APIs.
- better definition of where binds can be used, or context-sensitive binds 
(e.g., most native binding APIs don't allow a bind for the table name or 
syntax keywords, should we continue to allow this at all, or constrain it to a 
different type of bind?)
- a more interactive method of scrolling fetch cursors (see fetch_scroll())
- better support for windows users.
- appropriate SCM support for developing the bundled DBDs and DBI 
independently.

I'm sure I missed a few things already stated, so please chime in if I did.

Thanks for your time,

-Erik