RE: [HACKERS] Concurrent VACUUM: first results

> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)org]On Behalf Of Tom Lane
> Sent: Tuesday, November 23, 1999 3:41 PM
> To: pgsql-hackers(at)postgreSQL(dot)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(at)tpf(dot)co(dot)jp