Re: [HACKERS] Concurrent VACUUM: first results - Mailing list pgsql-hackers

From Vadim Mikheev
Subject Re: [HACKERS] Concurrent VACUUM: first results
Date
Msg-id 383E1B6F.1A0E08EF@krs.ru
Whole thread Raw
In response to Re: [HACKERS] Concurrent VACUUM: first results  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [HACKERS] Concurrent VACUUM: first results  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Concurrent VACUUM: first results
Next
From: Vadim Mikheev
Date:
Subject: Re: [GENERAL] drop/rename table and transactions