>
> > 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
