X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 8A202D1D26A for ; Sat, 7 Feb 2004 05:07:22 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 46166-05 for ; Sat, 7 Feb 2004 01:07:21 -0400 (AST) Received: from stubee.d2hosting.net (d2hosting.net [66.70.41.160]) by svr1.postgresql.org (Postfix) with ESMTP id 222A5D1C517 for ; Sat, 7 Feb 2004 01:07:20 -0400 (AST) Received: from idigx.com (ca-whlywd-cuda7-c5a-167.stmnca.adelphia.net [24.55.145.167]) by stubee.d2hosting.net (8.11.6/linuxconf) with ESMTP id i1757Dc03945; Fri, 6 Feb 2004 23:07:13 -0600 Message-ID: <40247280.2010102@idigx.com> Date: Fri, 06 Feb 2004 21:07:12 -0800 From: Thomas Swan User-Agent: Mozilla Thunderbird 0.5b (Windows/20040201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Treat Cc: Josh Berkus , Tom Lane , pgsql-hackers@postgresql.org Subject: Re: Preventing duplicate vacuums? References: <200402051237.14615.josh@agliodbs.com> <11820.1076015269@sss.pgh.pa.us> <200402051351.49983.josh@agliodbs.com> <1076106724.30335.41.camel@camel> In-Reply-To: <1076106724.30335.41.camel@camel> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200402/249 X-Sequence-Number: 49838 Robert Treat wrote: >On Thu, 2004-02-05 at 16:51, Josh Berkus wrote: > > >>Tom, >> >> >> >>>Yes we do: there's a lock. >>> >>> >>Sorry, bad test. Forget I said anything. >> >>Personally, I would like to have the 2nd vacuum error out instead of blocking. >>However, I'll bet that a lot of people won't agree with me. >> >> >> > >Don't know if I would agree for sure, but i the second vacuum could see >that it is being blocked by the current vacuum, exiting out would be a >bonus, since in most scenarios you don't need to run that second vacuum >so it just ends up wasting resources (or clogging other things up with >it lock) > > > What about a situation where someone would have lazy vacuums cron'd and it takes longer to complete the vacuum than the interval between vacuums. You could wind up with an ever increasing queue of vacuums. Erroring out with a "vacuum already in progress" might be useful.