Re: long running transactions

От: Tom Lane
Тема: Re: long running transactions
Дата: ,
Msg-id: 528.1160503495@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: long running transactions  (Tobias Brox)
Ответы: Re: long running transactions  (Tobias Brox)
Список: 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, )

Tobias Brox <> writes:
> (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 ()

That doesn't look particularly blocked, and if you are seeing
reads/writes too, then it's doing something.

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

Perhaps you have overly aggressive vacuum cost delay settings?

            regards, tom lane


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

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