| From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> | 
|---|---|
| To: | Gary Webster <webster(at)lexmark(dot)com> | 
| Cc: | pgsql-admin(at)postgresql(dot)org | 
| Subject: | Re: db size growing out of control when using clustered Jackrabbit | 
| Date: | 2012-07-25 18:44:44 | 
| Message-ID: | 50103E9C.2050301@commandprompt.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-admin | 
On 07/25/2012 11:37 AM, Gary Webster wrote:
>     This is a cluster issue, not a database issue. So if you have an
>     idnle in transaction, then it is affecting your JCR schema as well.
>
> OK, how do I track/debug/stop the "idle in transaction"s ?
Well idle in transaction is ALWAYS a code issue. You have code that is 
executing that is starting a transaction, leaving the connection open 
while not closing (committing/rollingback) the transaction.
You could turn on query logging and make sure pid and timestamp is in 
the log_line_prefix. They you can see what pids are idle in transaction 
and trace to what the last query was.
o you mean autovacuum, or something else?
>
>
>     I mean autovacuum.
>
> I was hoping to find more of a 'root cause' (eg. jackrabbit config) for
> this issue.
> I can't believe that this table is supposed to be getting so big, to
> even require much vacuuming.
Any update/delete to that table is going to cause bloat, autovacuum 
cleans that up. If it can. If it can't, it will just continously grow.
Sincerely,
jD
-- 
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
@cmdpromptinc - 509-416-6579
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Markus | 2012-07-26 07:44:21 | problems with access into system catalogs | 
| Previous Message | Gary Webster | 2012-07-25 18:37:18 | Re: db size growing out of control when using clustered Jackrabbit |