Jim C. Nasby wrote:
> On Wed, Jun 21, 2006 at 01:21:05PM -0300, jody brownell wrote:
>> Jun 21 13:04:04 vanquish postgres[3311]: [19-1] DEBUG: "target": removed
>> 5645231 row versions in 106508 pages
>> Jun 21 13:04:04 vanquish postgres[3311]: [19-2] DETAIL: CPU 3.37s/1.23u sec
>> elapsed 40.6
Hi, Csaba,
Csaba Nagy wrote:
> Well, your application might be completely well behaved and still your
> DBA (or your favorite DB access tool for that matter) can leave open
> transactions in an interactive session. It never hurts to check if you
> actually have "idle in transaction" sessions. It
Well, for one we did introduce a TX leak which was preventing autovac from
running. I guess that was _the_ issue.
I have since fixed it and an now testing looks much better, nothing
concerning
(fingers crossed until morning :)). debug logs are full of vac/anal of the
tables... so, for
On Wed, Jun 21, 2006 at 04:41:45PM -0300, jody brownell wrote:
> BTW, in production with a similar load - autovacuum with default out of the
> box
> settings seems to work quite well
>
> I double checked this earlier today.
So what's different between production and the machine with the pr
BTW, in production with a similar load - autovacuum with default out of the box
settings seems to work quite well
I double checked this earlier today.
On Wednesday 21 June 2006 16:38, Jim C. Nasby wrote:
> 5
---(end of broadcast)---
TIP 5: do
OK this was over a 12 - 16 hour period of not having anything done with it
though right?
I am assuming if autovacuum were active through out that period, we would be
somewhat better off ...is that not accurate?
On Wednesday 21 June 2006 16:38, Jim C. Nasby wrote:
> 5
-
On Wed, Jun 21, 2006 at 01:21:05PM -0300, jody brownell wrote:
> Jun 21 13:04:04 vanquish postgres[3311]: [19-1] DEBUG: "target": removed
> 5645231 row versions in 106508 pages
> Jun 21 13:04:04 vanquish postgres[3311]: [19-2] DETAIL: CPU 3.37s/1.23u sec
> elapsed 40.63 sec.
> Jun 21 13:04:04 v
block and row are always configured on - they are my friend :)
thanks
On Wednesday 21 June 2006 13:44, Csaba Nagy wrote:
> On Wed, 2006-06-21 at 18:39, jody brownell wrote:
> > that is exactly what I am seeing, one process, no change, always in idle
> > while the others are constantly
> > changin
On Wed, 2006-06-21 at 18:39, jody brownell wrote:
> that is exactly what I am seeing, one process, no change, always in idle
> while the others are constantly
> changing their state.
>
> looks like someone opened a tx then is blocking on a queue lock or something.
> dang.
Don't forget to check
that is exactly what I am seeing, one process, no change, always in idle while
the others are constantly
changing their state.
looks like someone opened a tx then is blocking on a queue lock or something.
dang.
On Wednesday 21 June 2006 13:36, Csaba Nagy wrote:
> On Wed, 2006-06-21 at 18:21,
On Wed, 2006-06-21 at 18:21, jody brownell wrote:
> That is interesting.
>
> There is one thread keeping a transaction open it appears from ps
>
> postgres: app app xxx(42644) idle in transaction
That shouldn't be a problem on itself, "idle in transaction" happens all
the time between 2 commands
Opps - that was confusing. The idle in transaction was from one box and the
autovacuum was from another.
So, one question was answered, auto vacuum is running and selecting the tables
but apparently not at the
same time as my app probably due to this "idle in transaction". I will track it
down
That is interesting.
There is one thread keeping a transaction open it appears from ps
postgres: app app xxx(42644) idle in transaction
however, I created a test table "t" not configured in pg_autovacuum. I inserted
a whack of rows and saw this.
Jun 21 12:38:45 vanquish postgres[1525]: [8-1] L
On Wed, 2006-06-21 at 17:27, jody brownell wrote:
> Our application is broken down quite well. We have two main writing processes
> writing to two separate sets of tables. No crossing over, nothign to prohibit
> the
> vacuuming in the nature which you describe.
It really doesn't matter what tab
Our application is broken down quite well. We have two main writing processes
writing to two separate sets of tables. No crossing over, nothign to prohibit
the
vacuuming in the nature which you describe.
My longest transaction on the tables in question are typically quite short
until
of cours
15 matches
Mail list logo
