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 14:44:29 |
Message-ID: | 18857.1124289869@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:
> On T, 2005-08-16 at 18:26 -0400, Tom Lane wrote:
>> 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.
> Actually any VACUUM, not only VACUUM ANALYSE, updates pg_class at the end.
> That's why I exclude only one of the transactions of the VACUUM command, and that
> transaction does not create any new tuples, it only removes old ones.
vac_update_relstats isn't the issue because it doesn't create a new
tuple. I was concerned about ANALYZE --- but since that's done in a
separate transaction that's not marked inVacuum, it's not at risk. So
OK, that's all right.
>> * 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).
> The cleanup transaction does no lookups in system catalogs.
Oh? It certainly has to open relations and indexes. I think that all
of that stuff may be done with SnapshotNow, rather than an xmin-related
snap, but it's still nervous-making.
>> 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.
> In my patch I specifically exclude TruncateSUBTRANS from using the
> inVacuum flag
You missed vac_truncate_clog, though.
> So I think that both your concerns expressed here are _already_
> addressed by the latest patch in:
> http://archives.postgresql.org/pgsql-patches/2005-07/msg00086.php
I have to admit that in my earlier message, I was looking at the version
of the patch that Bruce had on his patch page --- which I now see was not
the latest. The idea of making GetOldestXmin only conditionally ignore
vacuums certainly makes it a lot safer.
> Please check the actual patch and advise if anything is still missing.
There's still a fair amount of breakage in this patch --- eg, in the
VACUUM FULL case it manages to invoke *both* full_vacuum_rel and
lazy_vacuum_rel --- but I think it can probably be made to work.
I'll take another pass at it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-08-17 14:51:49 | Re: pthread stack on FreeBSD WAS: HEAD doesn't cope with libraries in non-default |
Previous Message | jtv | 2005-08-17 14:03:15 | Re: transactions not working properly ? |