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(at)tpf(dot)co(dot)jp