Re: [HACKERS] Concurrent VACUUM: first results
От | Vadim Mikheev |
---|---|
Тема | Re: [HACKERS] Concurrent VACUUM: first results |
Дата | |
Msg-id | 383E1B6F.1A0E08EF@krs.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] Concurrent VACUUM: first results (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Concurrent VACUUM: first results
|
Список | pgsql-hackers |
Bruce Momjian wrote: > > > /* > > * We have to commit our tuple' movings before we'll truncate ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > * relation, but we shouldn't lose our locks. And so - quick hack: ^^^^^^^^ ... or moved tuples may be lost in the case of DB/OS crash etc that may occur after truncation but before commit... > > * flush buffers and record status of current transaction as > > * committed, and continue. - vadim 11/13/96 > > */ > > FlushBufferPool(!TransactionFlushEnabled()); > > TransactionIdCommit(myXID); > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > FlushBufferPool(!TransactionFlushEnabled()); > > } > > > > vc_updstats() may be called in the already committed transaction. > > Oh, that is tricky that they have committed the transaction and continue > working in an already committed. Yikes. Any idea why we have to commit > it early? Vadim
В списке pgsql-hackers по дате отправления: