RE: [HACKERS] Concurrent VACUUM: first results

>
> > "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> > > CommitTransactionCommand() is executed at the end of vc_getrels()
> > > and vc_delhilowstats() is executed without StartTransactionCommand().
> >
> > Oooh, good eye! I wonder how long that bug's been there?
> >
> > I'm still inclined to remove that call to vc_delhilowstats, because it
> > seems like a global delete of statistics can't help but be a problem.
> > But if we keep it, you're dead right: it has to be inside a transaction.
> >
>
> With the new pg_statistic cache, you can efficiently do a heap_insert or
> heap_replace dending on whether an entry already exists. In the old
> code, that was hard because you had to scan entire table looking for a
> match so I just did a delete, and they I knew to do an insert.
>

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.

Moreover duplicate index check is useless. The check is done
after heap tuples are inserted(and committed).

Should vc_updstats() be moved before TransactionIdCommit() ?
I'm not sure.

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp