Обсуждение: PooledConnectionImpl problem

Hey all -

I've found a bug in org.postgresql.jdbc2.optional.PooledConnectionImpl.
The problem is that if you create a java.sql.Statement from
PooledConnectionImpl, then call getConnection() from that Statement, you
get back a java.sql.Connection, not a javax.sql.PooledConnection. So,
statement.getConnection().close() actually closes the physical
connection instead of recycling it to the pool.

The underlying reason for this is that PooledConnectionImpl is
implemented as a Proxy and doesn't override createStatement() or
prepareStatement() to substitute itself in as the Connection for the
created Statement. (Of course, overriding these methods is not so simple
- an org.postgresql.Jdbc2Statement requires a Jdbc2Connection in its
constructor, and the Proxy only implements java.sql.Connection.)

I'm hoping that someone familiar with the code can comment on the
following solutions:

1. The way that results from trying to keep the Proxy: Change
AbstractJdbc2Connection from an abstract class to an interface
(IJdbc2Connection) and make the Proxy implement IJdbc2Connection instead
of java.sql.Connection. Tweak Jdbc2Statement, Jdbc2PreparedStatement
etc. to use IJdbc2Connection instead of AbstractJdbc2Connection.

2. The non-Proxy way: Make PooledConnectionImpl an extension of
Jdbc2Connection. This has the disadvantage noted in the current code
that it won't automatically work for subsequent JDBC revisions. I guess
if it'll work to make an AbstractJdbc2PooledConnection, maybe that can
be worked around, too.

3. The lazy, unhelpful way: change my code to stop closing connections
retrieved from getConnection().

If you have any opinions or insight, or if this all just hopelessly
obtuse, let me know.

Mike

So, judging by the lack of response to my message below, I assume I'm on
my own...

One more general question that affects Connection handles retrieved from
PooledConnections - use of the Statement.getConnection() method doesn't
imply that you are getting a "physical connection", does it? If so, then
I suppose the current behavior of the PooledConnectionImpl would be
correct.

Mike

On Fri, Dec 06, 2002 at 10:24:13AM -0500, Mike Beachy wrote:
>
> Hey all -
>
> I've found a bug in org.postgresql.jdbc2.optional.PooledConnectionImpl.
> The problem is that if you create a java.sql.Statement from
> PooledConnectionImpl, then call getConnection() from that Statement, you
> get back a java.sql.Connection, not a javax.sql.PooledConnection. So,
> statement.getConnection().close() actually closes the physical
> connection instead of recycling it to the pool.
>
> The underlying reason for this is that PooledConnectionImpl is
> implemented as a Proxy and doesn't override createStatement() or
> prepareStatement() to substitute itself in as the Connection for the
> created Statement. (Of course, overriding these methods is not so simple
> - an org.postgresql.Jdbc2Statement requires a Jdbc2Connection in its
> constructor, and the Proxy only implements java.sql.Connection.)
>
> I'm hoping that someone familiar with the code can comment on the
> following solutions:
>
> 1. The way that results from trying to keep the Proxy: Change
> AbstractJdbc2Connection from an abstract class to an interface
> (IJdbc2Connection) and make the Proxy implement IJdbc2Connection instead
> of java.sql.Connection. Tweak Jdbc2Statement, Jdbc2PreparedStatement
> etc. to use IJdbc2Connection instead of AbstractJdbc2Connection.
>
> 2. The non-Proxy way: Make PooledConnectionImpl an extension of
> Jdbc2Connection. This has the disadvantage noted in the current code
> that it won't automatically work for subsequent JDBC revisions. I guess
> if it'll work to make an AbstractJdbc2PooledConnection, maybe that can
> be worked around, too.
>
> 3. The lazy, unhelpful way: change my code to stop closing connections
> retrieved from getConnection().
>
> If you have any opinions or insight, or if this all just hopelessly
> obtuse, let me know.
>
> Mike
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

On Mon, 9 Dec 2002, Mike Beachy wrote:

> So, judging by the lack of response to my message below, I assume I'm on
> my own...

I know Barry Lind, one of the key maintainers is on vacation at the
moment.  I am interested in this issue as well, but haven't had the time
to a look at it in detail.

My initial reaction to your concerns of turning the PooledConnectionImpl
into a Jdbc2Connection is that it might be able to be solved by an
explicit cast somewhere.  It seems that anything using the jdbc2 optional
package must be backed by a real Jdbc2Connection even if that isn't clear
from the "extends" and "implements" attributes of the class definitions.

Kris Jurka

> One more general question that affects Connection handles retrieved from
> PooledConnections - use of the Statement.getConnection() method doesn't
> imply that you are getting a "physical connection", does it? If so, then
> I suppose the current behavior of the PooledConnectionImpl would be
> correct.
>
> Mike
>
> On Fri, Dec 06, 2002 at 10:24:13AM -0500, Mike Beachy wrote:
> >
> > Hey all -
> >
> > I've found a bug in org.postgresql.jdbc2.optional.PooledConnectionImpl.
> > The problem is that if you create a java.sql.Statement from
> > PooledConnectionImpl, then call getConnection() from that Statement, you
> > get back a java.sql.Connection, not a javax.sql.PooledConnection. So,
> > statement.getConnection().close() actually closes the physical
> > connection instead of recycling it to the pool.
> >
> > The underlying reason for this is that PooledConnectionImpl is
> > implemented as a Proxy and doesn't override createStatement() or
> > prepareStatement() to substitute itself in as the Connection for the
> > created Statement. (Of course, overriding these methods is not so simple
> > - an org.postgresql.Jdbc2Statement requires a Jdbc2Connection in its
> > constructor, and the Proxy only implements java.sql.Connection.)
> >
> > I'm hoping that someone familiar with the code can comment on the
> > following solutions:
> >
> > 1. The way that results from trying to keep the Proxy: Change
> > AbstractJdbc2Connection from an abstract class to an interface
> > (IJdbc2Connection) and make the Proxy implement IJdbc2Connection instead
> > of java.sql.Connection. Tweak Jdbc2Statement, Jdbc2PreparedStatement
> > etc. to use IJdbc2Connection instead of AbstractJdbc2Connection.
> >
> > 2. The non-Proxy way: Make PooledConnectionImpl an extension of
> > Jdbc2Connection. This has the disadvantage noted in the current code
> > that it won't automatically work for subsequent JDBC revisions. I guess
> > if it'll work to make an AbstractJdbc2PooledConnection, maybe that can
> > be worked around, too.
> >
> > 3. The lazy, unhelpful way: change my code to stop closing connections
> > retrieved from getConnection().
> >
> > If you have any opinions or insight, or if this all just hopelessly
> > obtuse, let me know.
> >
> > Mike
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.org
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

Mike,

Sorry, I missed this earlier. I am trying to recall who wrote the
pooling stuff, and at the moment it is escaping me. Can you send us a
patch if you manage to get it fixed?

Dave
On Mon, 2002-12-09 at 16:37, Mike Beachy wrote:
> So, judging by the lack of response to my message below, I assume I'm on
> my own...
>
> One more general question that affects Connection handles retrieved from
> PooledConnections - use of the Statement.getConnection() method doesn't
> imply that you are getting a "physical connection", does it? If so, then
> I suppose the current behavior of the PooledConnectionImpl would be
> correct.
>
> Mike
>
> On Fri, Dec 06, 2002 at 10:24:13AM -0500, Mike Beachy wrote:
> >
> > Hey all -
> >
> > I've found a bug in org.postgresql.jdbc2.optional.PooledConnectionImpl.
> > The problem is that if you create a java.sql.Statement from
> > PooledConnectionImpl, then call getConnection() from that Statement, you
> > get back a java.sql.Connection, not a javax.sql.PooledConnection. So,
> > statement.getConnection().close() actually closes the physical
> > connection instead of recycling it to the pool.
> >
> > The underlying reason for this is that PooledConnectionImpl is
> > implemented as a Proxy and doesn't override createStatement() or
> > prepareStatement() to substitute itself in as the Connection for the
> > created Statement. (Of course, overriding these methods is not so simple
> > - an org.postgresql.Jdbc2Statement requires a Jdbc2Connection in its
> > constructor, and the Proxy only implements java.sql.Connection.)
> >
> > I'm hoping that someone familiar with the code can comment on the
> > following solutions:
> >
> > 1. The way that results from trying to keep the Proxy: Change
> > AbstractJdbc2Connection from an abstract class to an interface
> > (IJdbc2Connection) and make the Proxy implement IJdbc2Connection instead
> > of java.sql.Connection. Tweak Jdbc2Statement, Jdbc2PreparedStatement
> > etc. to use IJdbc2Connection instead of AbstractJdbc2Connection.
> >
> > 2. The non-Proxy way: Make PooledConnectionImpl an extension of
> > Jdbc2Connection. This has the disadvantage noted in the current code
> > that it won't automatically work for subsequent JDBC revisions. I guess
> > if it'll work to make an AbstractJdbc2PooledConnection, maybe that can
> > be worked around, too.
> >
> > 3. The lazy, unhelpful way: change my code to stop closing connections
> > retrieved from getConnection().
> >
> > If you have any opinions or insight, or if this all just hopelessly
> > obtuse, let me know.
> >
> > Mike
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.org
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Dave Cramer <Dave@micro-automation.net>

On 9 Dec 2002, Dave Cramer wrote:
> Mike,
>
> Sorry, I missed this earlier. I am trying to recall who wrote the
> pooling stuff, and at the moment it is escaping me. Can you send us a
> patch if you manage to get it fixed?

    You mean it isn't obvious from the @author tag in the header?
Sorry, I've been out of it for a while too.
    Mike, as for the issues below, it would be best if the Statement,
PreparedStatement, and CallableStatement all use a handler that hands back
a PooledConnectionImpl, not a Connection or PooledConnection.  It's easy
enough for the ConnectionHandler to hand out further proxies.  I can send
along a patch for this.
    I don't follow the specific arguments you're making with regard to
constructors and whatnot -- we're never going to be constructing a new
Statement, just wrapping the one that's already returned by the real
Connection, as ConnectionHandler wraps a Connection.

Aaron

> On Mon, 2002-12-09 at 16:37, Mike Beachy wrote:
> > So, judging by the lack of response to my message below, I assume I'm on
> > my own...
> >
> > One more general question that affects Connection handles retrieved from
> > PooledConnections - use of the Statement.getConnection() method doesn't
> > imply that you are getting a "physical connection", does it? If so, then
> > I suppose the current behavior of the PooledConnectionImpl would be
> > correct.
> >
> > Mike
> >
> > On Fri, Dec 06, 2002 at 10:24:13AM -0500, Mike Beachy wrote:
> > >
> > > Hey all -
> > >
> > > I've found a bug in org.postgresql.jdbc2.optional.PooledConnectionImpl.
> > > The problem is that if you create a java.sql.Statement from
> > > PooledConnectionImpl, then call getConnection() from that Statement, you
> > > get back a java.sql.Connection, not a javax.sql.PooledConnection. So,
> > > statement.getConnection().close() actually closes the physical
> > > connection instead of recycling it to the pool.
> > >
> > > The underlying reason for this is that PooledConnectionImpl is
> > > implemented as a Proxy and doesn't override createStatement() or
> > > prepareStatement() to substitute itself in as the Connection for the
> > > created Statement. (Of course, overriding these methods is not so simple
> > > - an org.postgresql.Jdbc2Statement requires a Jdbc2Connection in its
> > > constructor, and the Proxy only implements java.sql.Connection.)
> > >
> > > I'm hoping that someone familiar with the code can comment on the
> > > following solutions:
> > >
> > > 1. The way that results from trying to keep the Proxy: Change
> > > AbstractJdbc2Connection from an abstract class to an interface
> > > (IJdbc2Connection) and make the Proxy implement IJdbc2Connection instead
> > > of java.sql.Connection. Tweak Jdbc2Statement, Jdbc2PreparedStatement
> > > etc. to use IJdbc2Connection instead of AbstractJdbc2Connection.
> > >
> > > 2. The non-Proxy way: Make PooledConnectionImpl an extension of
> > > Jdbc2Connection. This has the disadvantage noted in the current code
> > > that it won't automatically work for subsequent JDBC revisions. I guess
> > > if it'll work to make an AbstractJdbc2PooledConnection, maybe that can
> > > be worked around, too.
> > >
> > > 3. The lazy, unhelpful way: change my code to stop closing connections
> > > retrieved from getConnection().
> > >
> > > If you have any opinions or insight, or if this all just hopelessly
> > > obtuse, let me know.
> > >
> > > Mike
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 6: Have you searched our list archives?
> > >
> > > http://archives.postgresql.org
> > >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
>

On Tue, Dec 10, 2002 at 05:47:00PM -0500, Aaron Mulder wrote:
>     Mike, as for the issues below, it would be best if the Statement,
> PreparedStatement, and CallableStatement all use a handler that hands back
> a PooledConnectionImpl, not a Connection or PooledConnection.  It's easy
> enough for the ConnectionHandler to hand out further proxies.  I can send
> along a patch for this.

Not sure what you mean here - at least, I can't see any way this would
fix the problem.

>     I don't follow the specific arguments you're making with regard to
> constructors and whatnot -- we're never going to be constructing a new
> Statement, just wrapping the one that's already returned by the real
> Connection, as ConnectionHandler wraps a Connection.

Okay - some terminology just to make sure I'm on the same page.

Connection handle: a generic term applied to the object that is given
out by PooledConnection.getConnection(). It acts just like a Connection
to the user. When close() is called on a Connection handle it is
returned to the pool, but the physical connection is not closed.

ConnectionHandler: Aaron's implementation of a Connection handle. It
implements the Connection interface, but is not a Jdbc2Connection,
because it uses java.reflect.Proxy to implement the interface.

Aaron, how is it that we're never going to be constructing a new
Statement?  Ack. I'm tired and likely to spout nonsense if I try to go
into this now.  Here's a test that can be added to ConnectionPoolTest
that should fail for the current code. Can you make it work?

        public void testStatementConnection()
        {
                try
                {
                        PooledConnection pc = getPooledConnection();
                        Connection con = pc.getConnection();
                        Statement s = con.createStatement();
                        Connection conRetrieved = s.getConnection();
                        assertTrue(con.getClass().equals(conRetrieved.getClass()));
                        assertTrue(con.equals(conRetrieved));
                }
                catch (SQLException e)
                {
                        fail(e.getMessage());
                }
        }

Mike


p.s. I think I see what you mean now - createStatement() gets added to
ConnectionHandler as one of the intercepted methods; it calls
createStatement() on the real Connection, but wraps the result in a
Statement proxy that intercepts calls to getConnection and returns the
Connection proxy instead of the actual Connection?

You are in a maze of twisty proxies, all alike...

On Tue, 10 Dec 2002, Mike Beachy wrote:
> p.s. I think I see what you mean now - createStatement() gets added to
> ConnectionHandler as one of the intercepted methods; it calls
> createStatement() on the real Connection, but wraps the result in a
> Statement proxy that intercepts calls to getConnection and returns the
> Connection proxy instead of the actual Connection?

    Exactly so.

    I've attached context diffs for
org.postgresql.test.jdbc2.optional.ConnectionPoolTest and
org.postgresql.jdbc2.optional.PooledConnectionImpl.
    The updated test does what Mike suggested, for Statements,
PreparedStatements, and CallableStatements.  The updated PooledConnection
adds a statement proxy as described above.

Aaron

P.S. When I run the test suite against my 7.2.2 server with the JDBC3
driver, I get a failure in DatabaseMetaData.testTables.  It is returning
the name of the first table in the database, so the table name criterion
doesn't seem to be working:

testTables(org.postgresql.test.jdbc2.DatabaseMetaDataTest)
junit.framework.AssertionFailedError at
org.postgresql.test.jdbc2.DatabaseMetaDataTest.testTables(DatabaseMetaDataTest.java:56)

Patch applied!

The test suite doesn't fail on my machine using a 7.3 backend??

Thanks,
Dave
On Tue, 2002-12-10 at 21:13, Aaron Mulder wrote:
> On Tue, 10 Dec 2002, Mike Beachy wrote:
> > p.s. I think I see what you mean now - createStatement() gets added to
> > ConnectionHandler as one of the intercepted methods; it calls
> > createStatement() on the real Connection, but wraps the result in a
> > Statement proxy that intercepts calls to getConnection and returns the
> > Connection proxy instead of the actual Connection?
>
>     Exactly so.
>
>     I've attached context diffs for
> org.postgresql.test.jdbc2.optional.ConnectionPoolTest and
> org.postgresql.jdbc2.optional.PooledConnectionImpl.
>     The updated test does what Mike suggested, for Statements,
> PreparedStatements, and CallableStatements.  The updated PooledConnection
> adds a statement proxy as described above.
>
> Aaron
>
> P.S. When I run the test suite against my 7.2.2 server with the JDBC3
> driver, I get a failure in DatabaseMetaData.testTables.  It is returning
> the name of the first table in the database, so the table name criterion
> doesn't seem to be working:
>
> testTables(org.postgresql.test.jdbc2.DatabaseMetaDataTest)
> junit.framework.AssertionFailedError at
> org.postgresql.test.jdbc2.DatabaseMetaDataTest.testTables(DatabaseMetaDataTest.java:56)
>
> ______________________________________________________________________
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
--
Dave Cramer <Dave@micro-automation.net>

On 11 Dec 2002, Dave Cramer wrote:
> Patch applied!

    Thanks.

> The test suite doesn't fail on my machine using a 7.3 backend??

    I have two Red Hat 8 machines with the default PG install (7.2.2).
Both fail the same item in the test suite.  Does anyone else have a Red
Hat 8 (or PG 7.2.2) box they can run the test suite against to check this?
    Also, Dave, do you have some other tables in the test database so
we're sure that the correct table isn't the first table listed just by
coincidence?  Perhaps we should adjust the setUp and tearDown for the
DatabaseMetaDataTest class to create table 'aaa' before 'testmetadata',
and 'zzz' after 'testmetadata', just to be sure.
    In fact, I've attached a patch for
org.postgresql.test.jdbc2.DatabaseMetaDataTest to do that.  Note there's
an extra println right before where I get the failure, and when I run the
patched test, it prints "TABLE NAME = aaa" despite the "testmetadat%"
criterion.

Thanks,
    Aaron

[junit] There was 1 failure:
[junit] 1) testTables(org.postgresql.test.jdbc2.DatabaseMetaDataTest)junit.framework.AssertionFailedError
[junit]     at org.postgresql.test.jdbc2.DatabaseMetaDataTest.testTables(DatabaseMetaDataTest.java:55)
[junit]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

When I put in some debugging output, this line gets the table name from
the ResultSet, which returns the name of the first table in the DB
(apparently alphabetically) instead of a table name matching the selection
criteria passed in ("testmetadat%").

Aaron

Aaron,

What other tables do you have in the database?

mine has
psql test
\d
             List of relations
 Schema |      Name      |   Type   | Owner
--------+----------------+----------+-------
 public | FOO            | table    | davec
 public | address        | table    | davec
 public | foo            | table    | davec
 public | foo_id_seq     | sequence | davec
 public | issue_priority | table    | davec
 public | issue_status   | table    | davec
 public | person         | table    | davec
 public | person_role    | table    | davec
 public | project        | table    | davec
 public | role           | table    | davec
(10 rows)


Dave
On Wed, 2002-12-11 at 10:05, Aaron Mulder wrote:
> On 11 Dec 2002, Dave Cramer wrote:
> > Patch applied!
>
>     Thanks.
>
> > The test suite doesn't fail on my machine using a 7.3 backend??
>
>     I have two Red Hat 8 machines with the default PG install (7.2.2).
> Both fail the same item in the test suite.  Does anyone else have a Red
> Hat 8 (or PG 7.2.2) box they can run the test suite against to check this?
>     Also, Dave, do you have some other tables in the test database so
> we're sure that the correct table isn't the first table listed just by
> coincidence?  Perhaps we should adjust the setUp and tearDown for the
> DatabaseMetaDataTest class to create table 'aaa' before 'testmetadata',
> and 'zzz' after 'testmetadata', just to be sure.
>     In fact, I've attached a patch for
> org.postgresql.test.jdbc2.DatabaseMetaDataTest to do that.  Note there's
> an extra println right before where I get the failure, and when I run the
> patched test, it prints "TABLE NAME = aaa" despite the "testmetadat%"
> criterion.
>
> Thanks,
>     Aaron
>
> [junit] There was 1 failure:
> [junit] 1) testTables(org.postgresql.test.jdbc2.DatabaseMetaDataTest)junit.framework.AssertionFailedError
> [junit]     at org.postgresql.test.jdbc2.DatabaseMetaDataTest.testTables(DatabaseMetaDataTest.java:55)
> [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> [junit]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> When I put in some debugging output, this line gets the table name from
> the ResultSet, which returns the name of the first table in the DB
> (apparently alphabetically) instead of a table name matching the selection
> criteria passed in ("testmetadat%").
>
> Aaron
>
> ______________________________________________________________________
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
--
Dave Cramer <Dave@micro-automation.net>

test=> \d
      List of relations
    Name     | Type  | Owner
-------------+-------+-------
 bar         | table | test
 foo         | table | test
 jmsjmsstate | table | test
 jmsjmsstore | table | test
(4 rows)


    With the CVS version of the test, I get "foo" instead of
"testmetadata".  When I patched the test to create "aaa" and "zzz" as
well, the method was getting "aaa" instead of "testmetadata" or any of the
tables listed here.

Aaron

On 11 Dec 2002, Dave Cramer wrote:
> Aaron,
>
> What other tables do you have in the database?
>
> mine has
> psql test
> \d
>              List of relations
>  Schema |      Name      |   Type   | Owner
> --------+----------------+----------+-------
>  public | FOO            | table    | davec
>  public | address        | table    | davec
>  public | foo            | table    | davec
>  public | foo_id_seq     | sequence | davec
>  public | issue_priority | table    | davec
>  public | issue_status   | table    | davec
>  public | person         | table    | davec
>  public | person_role    | table    | davec
>  public | project        | table    | davec
>  public | role           | table    | davec
> (10 rows)
>
>
> Dave
> On Wed, 2002-12-11 at 10:05, Aaron Mulder wrote:
> > On 11 Dec 2002, Dave Cramer wrote:
> > > Patch applied!
> >
> >     Thanks.
> >
> > > The test suite doesn't fail on my machine using a 7.3 backend??
> >
> >     I have two Red Hat 8 machines with the default PG install (7.2.2).
> > Both fail the same item in the test suite.  Does anyone else have a Red
> > Hat 8 (or PG 7.2.2) box they can run the test suite against to check this?
> >     Also, Dave, do you have some other tables in the test database so
> > we're sure that the correct table isn't the first table listed just by
> > coincidence?  Perhaps we should adjust the setUp and tearDown for the
> > DatabaseMetaDataTest class to create table 'aaa' before 'testmetadata',
> > and 'zzz' after 'testmetadata', just to be sure.
> >     In fact, I've attached a patch for
> > org.postgresql.test.jdbc2.DatabaseMetaDataTest to do that.  Note there's
> > an extra println right before where I get the failure, and when I run the
> > patched test, it prints "TABLE NAME = aaa" despite the "testmetadat%"
> > criterion.
> >
> > Thanks,
> >     Aaron
> >
> > [junit] There was 1 failure:
> > [junit] 1) testTables(org.postgresql.test.jdbc2.DatabaseMetaDataTest)junit.framework.AssertionFailedError
> > [junit]     at org.postgresql.test.jdbc2.DatabaseMetaDataTest.testTables(DatabaseMetaDataTest.java:55)
> > [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > [junit]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >
> > When I put in some debugging output, this line gets the table name from
> > the ResultSet, which returns the name of the first table in the DB
> > (apparently alphabetically) instead of a table name matching the selection
> > criteria passed in ("testmetadat%").
> >
> > Aaron
> >
> > ______________________________________________________________________
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.org
>

Well apparently we have a problem here.

if you have logging turned on, can you cut and past the sql that is
being executed by getTables ?

Dave
On Wed, 2002-12-11 at 13:35, Aaron Mulder wrote:
> test=> \d
>       List of relations
>     Name     | Type  | Owner
> -------------+-------+-------
>  bar         | table | test
>  foo         | table | test
>  jmsjmsstate | table | test
>  jmsjmsstore | table | test
> (4 rows)
>
>
>     With the CVS version of the test, I get "foo" instead of
> "testmetadata".  When I patched the test to create "aaa" and "zzz" as
> well, the method was getting "aaa" instead of "testmetadata" or any of the
> tables listed here.
>
> Aaron
>
> On 11 Dec 2002, Dave Cramer wrote:
> > Aaron,
> >
> > What other tables do you have in the database?
> >
> > mine has
> > psql test
> > \d
> >              List of relations
> >  Schema |      Name      |   Type   | Owner
> > --------+----------------+----------+-------
> >  public | FOO            | table    | davec
> >  public | address        | table    | davec
> >  public | foo            | table    | davec
> >  public | foo_id_seq     | sequence | davec
> >  public | issue_priority | table    | davec
> >  public | issue_status   | table    | davec
> >  public | person         | table    | davec
> >  public | person_role    | table    | davec
> >  public | project        | table    | davec
> >  public | role           | table    | davec
> > (10 rows)
> >
> >
> > Dave
> > On Wed, 2002-12-11 at 10:05, Aaron Mulder wrote:
> > > On 11 Dec 2002, Dave Cramer wrote:
> > > > Patch applied!
> > >
> > >     Thanks.
> > >
> > > > The test suite doesn't fail on my machine using a 7.3 backend??
> > >
> > >     I have two Red Hat 8 machines with the default PG install (7.2.2).
> > > Both fail the same item in the test suite.  Does anyone else have a Red
> > > Hat 8 (or PG 7.2.2) box they can run the test suite against to check this?
> > >     Also, Dave, do you have some other tables in the test database so
> > > we're sure that the correct table isn't the first table listed just by
> > > coincidence?  Perhaps we should adjust the setUp and tearDown for the
> > > DatabaseMetaDataTest class to create table 'aaa' before 'testmetadata',
> > > and 'zzz' after 'testmetadata', just to be sure.
> > >     In fact, I've attached a patch for
> > > org.postgresql.test.jdbc2.DatabaseMetaDataTest to do that.  Note there's
> > > an extra println right before where I get the failure, and when I run the
> > > patched test, it prints "TABLE NAME = aaa" despite the "testmetadat%"
> > > criterion.
> > >
> > > Thanks,
> > >     Aaron
> > >
> > > [junit] There was 1 failure:
> > > [junit] 1) testTables(org.postgresql.test.jdbc2.DatabaseMetaDataTest)junit.framework.AssertionFailedError
> > > [junit]     at org.postgresql.test.jdbc2.DatabaseMetaDataTest.testTables(DatabaseMetaDataTest.java:55)
> > > [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > [junit]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > >
> > > When I put in some debugging output, this line gets the table name from
> > > the ResultSet, which returns the name of the first table in the DB
> > > (apparently alphabetically) instead of a table name matching the selection
> > > criteria passed in ("testmetadat%").
> > >
> > > Aaron
> > >
> > > ______________________________________________________________________
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 6: Have you searched our list archives?
> > >
> > > http://archives.postgresql.org
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Dave Cramer <Dave@micro-automation.net>

I have a fix for this I will submit this afternoon.

On 11 Dec 2002, Dave Cramer wrote:

> Well apparently we have a problem here.
>
> if you have logging turned on, can you cut and past the sql that is
> being executed by getTables ?
>
> Dave
> On Wed, 2002-12-11 at 13:35, Aaron Mulder wrote:
> > test=> \d
> >       List of relations
> >     Name     | Type  | Owner
> > -------------+-------+-------
> >  bar         | table | test
> >  foo         | table | test
> >  jmsjmsstate | table | test
> >  jmsjmsstore | table | test
> > (4 rows)
> >
> >
> >     With the CVS version of the test, I get "foo" instead of
> > "testmetadata".  When I patched the test to create "aaa" and "zzz" as
> > well, the method was getting "aaa" instead of "testmetadata" or any of the
> > tables listed here.
> >
> > Aaron
> >
> > On 11 Dec 2002, Dave Cramer wrote:
> > > Aaron,
> > >
> > > What other tables do you have in the database?
> > >
> > > mine has
> > > psql test
> > > \d
> > >              List of relations
> > >  Schema |      Name      |   Type   | Owner
> > > --------+----------------+----------+-------
> > >  public | FOO            | table    | davec
> > >  public | address        | table    | davec
> > >  public | foo            | table    | davec
> > >  public | foo_id_seq     | sequence | davec
> > >  public | issue_priority | table    | davec
> > >  public | issue_status   | table    | davec
> > >  public | person         | table    | davec
> > >  public | person_role    | table    | davec
> > >  public | project        | table    | davec
> > >  public | role           | table    | davec
> > > (10 rows)
> > >
> > >
> > > Dave
> > > On Wed, 2002-12-11 at 10:05, Aaron Mulder wrote:
> > > > On 11 Dec 2002, Dave Cramer wrote:
> > > > > Patch applied!
> > > >
> > > >     Thanks.
> > > >
> > > > > The test suite doesn't fail on my machine using a 7.3 backend??
> > > >
> > > >     I have two Red Hat 8 machines with the default PG install (7.2.2).
> > > > Both fail the same item in the test suite.  Does anyone else have a Red
> > > > Hat 8 (or PG 7.2.2) box they can run the test suite against to check this?
> > > >     Also, Dave, do you have some other tables in the test database so
> > > > we're sure that the correct table isn't the first table listed just by
> > > > coincidence?  Perhaps we should adjust the setUp and tearDown for the
> > > > DatabaseMetaDataTest class to create table 'aaa' before 'testmetadata',
> > > > and 'zzz' after 'testmetadata', just to be sure.
> > > >     In fact, I've attached a patch for
> > > > org.postgresql.test.jdbc2.DatabaseMetaDataTest to do that.  Note there's
> > > > an extra println right before where I get the failure, and when I run the
> > > > patched test, it prints "TABLE NAME = aaa" despite the "testmetadat%"
> > > > criterion.
> > > >
> > > > Thanks,
> > > >     Aaron
> > > >
> > > > [junit] There was 1 failure:
> > > > [junit] 1) testTables(org.postgresql.test.jdbc2.DatabaseMetaDataTest)junit.framework.AssertionFailedError
> > > > [junit]     at org.postgresql.test.jdbc2.DatabaseMetaDataTest.testTables(DatabaseMetaDataTest.java:55)
> > > > [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > [junit]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > >
> > > > When I put in some debugging output, this line gets the table name from
> > > > the ResultSet, which returns the name of the first table in the DB
> > > > (apparently alphabetically) instead of a table name matching the selection
> > > > criteria passed in ("testmetadat%").
> > > >
> > > > Aaron
> > > >
> > > > ______________________________________________________________________
> > > >
> > > > ---------------------------(end of broadcast)---------------------------
> > > > TIP 6: Have you searched our list archives?
> > > >
> > > > http://archives.postgresql.org
> > >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
> --
> Dave Cramer <Dave@micro-automation.net>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

This patch fixes the following two problems:

getTables did not use the tableNamePattern argument on server versions
less than 7.3

getTables, getColumns, and getProcedures failed when running against a 7.1
server because of a different version of the pg_description system table.

Kris Jurka

Patch applied

Thanks Kris!
On Wed, 2002-12-11 at 15:26, Kris Jurka wrote:
> This patch fixes the following two problems:
>
> getTables did not use the tableNamePattern argument on server versions
> less than 7.3
>
> getTables, getColumns, and getProcedures failed when running against a 7.1
> server because of a different version of the pg_description system table.
>
> Kris Jurka
>
> ______________________________________________________________________
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Dave Cramer <Dave@micro-automation.net>