RE: [HACKERS] Concurrent VACUUM: first results

>
> > I have a anxiety about the index of pg_statistic(pg_statistic
> itself also
> > ?).
> >
> > vc_updstats() may be called in immediately committed mode.
> > vacuum calls TransactionIdCommit() after moving tuples in order
> > to delete index tuples and truncate the relation safely.
> >
> > It's necessary but the state is out of PostgreSQL's recovery
> > mechanism.
> > heap_insert() is imediately committed. If index_insert() fails
> > there remains a heap tuple which doesn't have a corresponding
> > index entry.
>
>
> Huh.  Heap_insert writes to disk, but there it is not used unless the
> transaction gets committed, right?
>

This could occur only in vacuum.
There's a quick hack in vc_rpfheap().
       if (num_moved > 0)       {
               /*                * We have to commit our tuple' movings before we'll
truncate                * relation, but we shouldn't lose our locks. And so - quick
hac
k:                * 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.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp