From: | John R Pierce <pierce(at)hogranch(dot)com> |
---|---|
To: | Kris Jurka <books(at)ejurka(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Connection.setReadOnly() |
Date: | 2009-12-11 00:33:46 |
Message-ID: | 4B21936A.9080805@hogranch.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Kris Jurka wrote:
> So if they go to the trouble of doing a setReadOnly call, why not
> simply do a setAutoCommit(true) call as well?
thats pretty much what they'll have to do. I guess setReadOnly() is
pretty much a non-op in pg-jdbc?
we're having such a problem with Idle in Transaction on this database
that I'm looking into writing a process killer that queries
pg_stat_activity every 10 minutes and does a pg_terminate_backend() on
PIDs older than some arbitrary threshold, maybe an hour.
we're still fixing oraclisms in the main application. the developers
wanted a mutex on the various 'back end' processes, so they have a
thread that connects, and did a lock on a row in a table (one row for
each named app that has to be a 1-of), then leave that transaction
going.... This works perfectly well on Oracle. On postgresql, 4-5
days later, its painful to see how much bloat is in this 70GB database,
and in fact, the autovacuum processes start stacking up on each other
and primariy application response time starts shooting up slower and
slower til the factory is slowing down, not good.... I've shown them
how to use pg_try_advisory_lock() to do the same thing.
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2009-12-11 00:41:28 | Re: Connection.setReadOnly() |
Previous Message | Kris Jurka | 2009-12-11 00:23:44 | Re: Connection.setReadOnly() |