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
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 |