Re: long running transactions

От: Tobias Brox
Тема: Re: long running transactions
Дата: ,
Msg-id: 20061010174955.GA284@oppetid.no
(см: обсуждение, исходный текст)
Ответ на: Re: long running transactions  (Tom Lane)
Ответы: Re: long running transactions  (Tom Lane)
Список: pgsql-performance

Скрыть дерево обсуждения

long running transactions  (Tobias Brox, )
 Re: long running transactions  (Tom Lane, )
  Re: long running transactions  (Tobias Brox, )
   Re: long running transactions  (Tobias Brox, )
    Re: long running transactions  (Tom Lane, )
     Re: long running transactions  (Tobias Brox, )
      Re: long running transactions  (Tom Lane, )
       Re: long running transactions  (Tobias Brox, )
        Re: long running transactions  (Tom Lane, )
         Re: long running transactions  (Tobias Brox, )
          Re: long running transactions  (Tom Lane, )
           Re: long running transactions  (Tobias Brox, )
            Re: long running transactions  (Tom Lane, )
             Re: long running transactions  (Tobias Brox, )

[Tom Lane - Tue at 01:18:27PM -0400]
> >> Hmph.  Is the autovac process actually doing anything (strace would be
> >> revealing)?

It's definitively doing something; mostly reading, but also some few
writes, semops and opens.

> If not, can you attach to the autovac process with gdb and
> >> get a stack trace to see where it's blocked?

(gdb) bt
#0  0xb7c599f8 in select () from /lib/tls/libc.so.6
#1  0x08253c53 in pg_usleep ()
#2  0x0812ee93 in vacuum_delay_point ()
#3  0x0812f2a5 in lazy_vacuum_rel ()
#4  0x0812ef7b in lazy_vacuum_rel ()
#5  0x0812b4b6 in vac_update_relstats ()
#6  0x0812a995 in vacuum ()
#7  0x0818d2ca in autovac_stopped ()
#8  0x0818ceae in autovac_stopped ()
#9  0x0818c848 in autovac_stopped ()
#10 0x0818c4e2 in autovac_start ()
#11 0x08192c11 in PostmasterMain ()
#12 0x08191dcf in PostmasterMain ()
#13 0x081541b1 in main ()

> It'll come back after the autovacuum naptime.  If it gets stuck again,
> please investigate.

It seems stuck, has had the same transid for a long while, and the
number of undeletable dead rows in our tables are increasing.



В списке pgsql-performance по дате сообщения:

От: Brendan Curran
Дата:
Сообщение: Re: Scrub one large table against another
От: Mark Kirkwood
Дата:
Сообщение: Re: Simple join optimized badly?