From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | "Blakely, Jerel \(Mission Systems\)" <Jerel(dot)Blakely(at)ngc(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Problem with jdbc connection behavior |
Date: | 2007-02-14 21:07:58 |
Message-ID: | 45D37A2E.9060703@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Blakely, Jerel (Mission Systems) wrote:
> The testcase code currently looks like this, I have tried rollback
> already. Since commits happen after each item it didn't change anything.
> ...
Hmm. I can't see any apparent reason why that wouldn't work. I'd suggest
setting these parameters in the server's postgresql.conf file to log all
the connections and statements and commits:
log_connections = on
log_disconnections = on
log_statement = 'all'
I'm thinking there's something in your environment inhibiting commits or
or something like that.
> Since my other post I now have noticed a problem with the drop table
> never returning.
> It is a simple: stmt.executeUpdate("DROP TABLE TEMP_TABLE");
Can you elaborate? Are you executing the drop table while the test case
is running, or is it just generally not returning?
> I have verified these test cases against Firebird, Sybase, and Oracle
> with no problems, I am beginning to think my Postgres install is cursed.
Yeah, I hate it when that happens ;).
Something you should be aware of is that unlike in most other DBMSs, DDL
statements like CREATE/DROP TABLE are transactional in PostgreSQL. If
you CREATE TABLE in one connection, it's not visible to others until commit.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Ken Johanson | 2007-02-15 04:31:43 | Re: Synthesize support for Statement.getGeneratedKeys()? |
Previous Message | Blakely, Jerel (Mission Systems) | 2007-02-14 20:44:44 | Re: Problem with jdbc connection behavior |