Re: autovacuum and default_transaction_isolation

Поиск
Список
Период
Сортировка
Искать
От
Kevin Grittner
Тема
Re: autovacuum and default_transaction_isolation
Дата
Msg-id
4ED5004902000025000435FE@gw.wicourts.gov
Ответ на
Список
Дерево обсуждения
autovacuum and default_transaction_isolation Dan Ports <drkp@csail.mit.edu>
Re: autovacuum and default_transaction_isolation Tom Lane <tgl@sss.pgh.pa.us>
Re: autovacuum and default_transaction_isolation Dan Ports <drkp@csail.mit.edu>
Re: autovacuum and default_transaction_isolation "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: autovacuum and default_transaction_isolation Tom Lane <tgl@sss.pgh.pa.us>
Re: autovacuum and default_transaction_isolation "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: autovacuum and default_transaction_isolation Tom Lane <tgl@sss.pgh.pa.us>
Re: autovacuum and default_transaction_isolation "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Dan Ports  wrote:
> I was doing some tests recently with default_transaction_isolation
> set to 'serializable' in postgresql.conf when I noticed pg_locks
> filling up with SIReadLocks rather more quickly than I expected.
> 
> After some investigation, I found that an autovacuum worker was
> starting a transaction at the default isolation level. While using
> a serializable transaction doesn't affect its behavior (because
> it's not using a MVCC snapshot), having a serializable transaction
> open prevents other concurrent serializable transactions and their
> predicate locks from being cleaned up. Since VACUUM on a large
> table can take a long time, this could affect many concurrent
> transactions.
> 
> My one-liner fix for this was to set
>   DefaultXactIsoLevel = XACT_READ_COMMITTED;
> in AutoVacWorkerMain.
Ouch!  I think this needs to be considered a significant bug!  Is it
too late to get this into 9.1.2?
-Kevin

В списке pgsql-hackers по дате отправления
От: Dan Ports
Дата:
От: Andres Freund
Дата:
FAQ