Re: Missing CONCURRENT VACUUM (Was: Release notes for

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannu(at)skype(dot)net>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Missing CONCURRENT VACUUM (Was: Release notes for
Date: 2005-08-17 18:48:09
Message-ID: 5302.1124304489@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hannu Krosing <hannu(at)skype(dot)net> writes:
> Please check the actual patch and advise if anything is still missing.

While testing this I realized that it does not in fact work as
advertised. It will only exclude long-running VACUUMs from other
VACUUMs' OldestXmin if *all* the transactions in the system are lazy
VACUUMs. If there is even one regular transaction in the system,
that transaction will include the VACUUMs in its MyProc->xmin, and
thence GetOldestXmin will have to include them in its result.

AFAICS the only way to fix this would be to exclude inVacuum
transactions from GetSnapshotData's calculations as well. That
makes the patch far more invasive, and I'm not confident I can work
out all the implications. (In particular, the consequences for
TransactionIdIsInProgress look bad. I don't think we want a VACUUM
to be seen as not-in-progress.)

So I'm bouncing this patch again...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-08-17 19:40:53 Re: PATCH to allow concurrent VACUUMs to not lock each
Previous Message Dave Cramer 2005-08-17 18:32:58 Re: pl/Ruby, deprecating plPython and Core