Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 60D3864FD6E for ; Tue, 28 Oct 2008 09:19:20 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 27682-01 for ; Tue, 28 Oct 2008 09:19:14 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.televork.ee (mail.televork.ee [81.21.241.190]) by postgresql.org (Postfix) with ESMTP id AA96164FD74 for ; Tue, 28 Oct 2008 09:19:14 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by mail.televork.ee (Postfix) with ESMTP id 210E738B8; Tue, 28 Oct 2008 14:19:11 +0200 (EET) X-Virus-Scanned: at mail.televork.ee Received: from mail.televork.ee ([81.21.241.190]) by localhost (mail.televork.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5synOeRbYeH; Tue, 28 Oct 2008 14:19:05 +0200 (EET) Received: from [127.0.0.1] (81-21-242-98.televork.ee [81.21.242.98]) by mail.televork.ee (Postfix) with ESMTP id EAE0B18269C; Tue, 28 Oct 2008 14:19:04 +0200 (EET) Subject: Re: VACUUMs and WAL From: Hannu Krosing To: Simon Riggs Cc: pgsql-hackers In-Reply-To: <1225188645.3971.118.camel@ebony.2ndQuadrant> References: <1225183785.3971.114.camel@ebony.2ndQuadrant> <1225187130.7721.5.camel@huvostro> <1225188645.3971.118.camel@ebony.2ndQuadrant> Content-Type: text/plain Date: Tue, 28 Oct 2008 14:19:04 +0200 Message-Id: <1225196344.7694.2.camel@huvostro> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200810/1387 X-Sequence-Number: 126404 On Tue, 2008-10-28 at 10:10 +0000, Simon Riggs wrote: > On Tue, 2008-10-28 at 11:45 +0200, Hannu Krosing wrote: > > On Tue, 2008-10-28 at 08:49 +0000, Simon Riggs wrote: > > > Looking at a VACUUM's WAL records makes me think twice about the way we > > > issue a VACUUM. > > > > > > 1. First we scan the heap, issuing a HEAP2 clean record for every block > > > that needs cleaning. > > > > IIRC the first heap pass just collects info and does nothing else. > > Is this just an empty/do-nothing WAL record ? > > 8.3 changed that; it used to work that way. I guess I never looked at > the amount of WAL being generated. I can't see how it is safe to do anything more than just lookups on first pass. There will be dangling index pointers if the system crashes/is rebooted or the vacuum is just interrupted after cleaning some heap pages but before cleaning corresponding index pages. --------------- Hannu