Skip site navigation (1) Skip section navigation (2)

Re: PATCH to allow concurrent VACUUMs to not lock each

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Hannu Krosing <hannu(at)tm(dot)ee>, Neil Conway <neilc(at)samurai(dot)com>,pgsql-patches(at)postgresql(dot)org
Subject: Re: PATCH to allow concurrent VACUUMs to not lock each
Date: 2005-08-14 16:56:06
Message-ID: 583.1124038566@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> Is there any particular reason for not putting it in 8.1 ?

> I thought there was still uncertainty about the patch.  Is there?

Considerable uncertainty, in my mind.  What we've got here is some
pretty fundamental hacking on the transaction visibility logic, and
neither Hannu nor anyone else has produced a convincing argument
that it's correct.  "It hasn't failed yet in my usage" isn't enough
to give me a good feeling about it.  Some specific concerns:

* Given that VACUUM ANALYZE does create new output tuples stamped with
its xid, I'm unclear on what happens in pg_statistic with this code in
place.  It seems entirely possible that someone might conclude the
analyze tuples are from a crashed transaction and mark them invalid
before the analyze can commit (notice TransactionIdIsInProgress does not
bother looking in PGPROC when the tuple xmin is less than RecentXmin).

* If the vacuum xact is older than what others think is the global xmin,
it could have problems with other vacuums removing tuples it should
still be able to see (presumably only in the system catalogs, so maybe
this isn't an issue, but I'm unsure).  A related scenario that I don't
think can be dismissed is someone truncating off part of pg_subtrans or
pg_multixact that the vacuum still needs.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-08-14 17:18:33
Subject: Re: psql SET/RESET/SHOW tab completion
Previous:From: Peter EisentrautDate: 2005-08-14 10:59:45
Subject: Re: SPARQL

pgsql-patches by date

Next:From: Tom LaneDate: 2005-08-14 16:58:55
Subject: Re: [HACKERS] For review: Server instrumentation patch
Previous:From: Andrew DunstanDate: 2005-08-14 16:26:02
Subject: Re: [HACKERS] For review: Server instrumentation patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group