> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Friday, November 26, 1999 2:56 PM
> To: Vadim Mikheev
> Cc: Bruce Momjian; Hiroshi Inoue; pgsql-hackers@postgreSQL.org
> Subject: Re: [HACKERS] Concurrent VACUUM: first results
>
>
> Vadim Mikheev <vadim@krs.ru> writes:
> >>>> * 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...
>
> I wonder whether there isn't a cleaner way to do this. What about
> removing this early commit, and doing everything else the way that
> VACUUM does it, except that the physical truncate of the relation
> file happens *after* the commit at the end of vc_vacone?
>
I think there exists another reason.
We couldn't delete index tuples for deleted but not yet committed
heap tuples.
If we could start another transaction without releasing exclusive
lock for the target relation,it would be better.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp