RE: [HACKERS] Concurrent VACUUM: first results

> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
> Sent: Tuesday, November 23, 1999 3:41 PM
> To: pgsql-hackers@postgreSQL.org
> Subject: [HACKERS] Concurrent VACUUM: first results
> 
> 
> Well, I diked out the code in vacuum.c that creates/deletes the pg_vlock
> lockfile, and tried it out.  Turns out it's not quite such a no-brainer
> as I'd hoped.  Several problems emerged:
> 
> 3. I tried running VACUUMs in parallel with the regress tests, and saw
> a lot of messages like
> NOTICE:  Rel tenk1: TID 1/31: InsertTransactionInProgress 29737 - 
> can't shrink relation
> Looking at the code, this is normal behavior for VACUUM when it sees
> not-yet-committed tuples, and has nothing to do with whether there's
> another VACUUM going on elsewhere.  BUT: why the heck are we getting
> these at all, especially on user tables?  VACUUM's grabbed an exclusive
> lock on the target table; shouldn't that mean that all write
> transactions on the target have committed?  This looks like it could
> be a symptom of a locking bug.
>

Doesn't DoCopy() in copy.c unlock the target relation too early
by heap_close() ?
Regards.

Hiroshi Inoue
Inoue@tpf.co.jp