On 07/26/2012 12:31 PM, Gary Webster wrote:
OK, I set "log_statement = "all""
The log grew to 1GB in ~minute! It is dominated by this one statement,
which occurs every ~1.4 sec:
"update WS_BUNDLE set BUNDLE_DATA = $1 where NODE_ID_HI = $2 and
NODE_ID_LO = $3"
parameter $1 is hex, over 6million
On Thu, Jul 26, 2012 at 1:31 PM, Gary Webster wrote:
> OK, I set "log_statement = "all""
> The log grew to 1GB in ~minute! It is dominated by this one statement,
> which occurs every ~1.4 sec:
> "update WS_BUNDLE set BUNDLE_DATA = $1 where NODE_ID_HI = $2 and NODE_ID_LO
> = $3"
> parameter $1 is
On Wed, Jul 25, 2012 at 2:44 PM, Joshua D. Drake wrote:
>
> 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
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.
On Tue, Jul 24, 2012 at 1:41 PM, Joshua D. Drake wrote:
>
> On 07/24/2012 08:58 AM, Gary Webster wrote:
>
>> Hello.
>> Thanks for the response.
>>
>> There are several 'idle in transaction' on this server/app, but to a
>> different db/schema.
>>
>
> This is a cluster issue, not a database issue. S
On 07/24/2012 08:58 AM, Gary Webster wrote:
Hello.
Thanks for the response.
There are several 'idle in transaction' on this server/app, but to a
different db/schema.
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
Gary Webster writes:
> By "routine maintenance", do you mean autovacuum, or something else?
> Autovacuum does appear to usually get 'auto-canceled' by a lock.
That's bad and you should look into the reason why it happens. Ordinary
DML (CRUD) operations should not kick autovac off a table. If it
Hello.
Thanks for the response.
There are several 'idle in transaction' on this server/app, but to a
different db/schema.
The "repository" (JCR) schema has only a few 'idle', none 'in transaction' .
By "routine maintenance", do you mean autovacuum, or something else?
Autovacuum does appear to usu
Hello.
Thanks for the response.
Autovacuum is set VERY aggressive.
However, it does not help with the ws_bundle Toast table.
A manual _full_ vacuum (not recommended?) does do the deed.
However, it often gives this error:
ERROR: missing chunk number 0 for toast value 639113 in pg_toast_533386
BT
On 07/24/2012 05:13 AM, Gary Webster wrote:
Hello. I'm hoping someone has seen this before.
We are trying to use Postgres Plus v9.1.3 as the Persistence Manager
in Jackrabbit (Apache JCR) clustering
(http://wiki.apache.org/jackrabbit/Clustering).
Whenever the JCR is under load, the ws_bundle T
On 07/23/2012 02:13 PM, Gary Webster wrote:
Hello. I'm hoping someone has seen this before.
We are trying to use Postgres Plus v9.1.3 as the Persistence Manager in
Jackrabbit (Apache JCR) clustering
(http://wiki.apache.org/jackrabbit/Clustering).
Whenever the JCR is under load, the ws_bundle TO
Hello. I'm hoping someone has seen this before.
We are trying to use Postgres Plus v9.1.3 as the Persistence Manager in
Jackrabbit (Apache JCR) clustering (
http://wiki.apache.org/jackrabbit/Clustering).
Whenever the JCR is under load, the ws_bundle TOAST table in the
repository schema, grows out
12 matches
Mail list logo
