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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Concurrent VACUUM: first results
Следующее
От: Vadim Mikheev
Дата:
Сообщение: Re: [GENERAL] drop/rename table and transactions