Re: PATCH to allow concurrent VACUUMs to not lock each
От | Tom Lane |
---|---|
Тема | Re: PATCH to allow concurrent VACUUMs to not lock each |
Дата | |
Msg-id | 583.1124038566@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: PATCH to allow concurrent VACUUMs to not lock each (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: PATCH to allow concurrent VACUUMs to not lock each
|
Список | pgsql-patches |
Bruce Momjian <pgman@candle.pha.pa.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
В списке pgsql-patches по дате отправления: