Skip site navigation (1) Skip section navigation (2)

Re: Hot Standby and VACUUM FULL

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hot Standby and VACUUM FULL
Date: 2010-01-31 20:06:44
Message-ID: 1264968404.13782.8513.camel@ebony (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sun, 2010-01-31 at 14:44 -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > Having said that I now realise a few things I didn't before:
> > * Approach (2) effects the core of Postgres, even if you don't use Hot
> > Standby.
> > * I've had to remove 7 sanity checks to get the first few VACUUMs
> > working. ISTM that removing various basic checks in the code is not a
> > good thing. 
> > * There are are more special cases than I realised at first: temp,
> > shared, with-toast, nailed, shared-and-nailed, pg_class, normal system.
> Quite honestly, these statements and the attached patch (which doesn't
> even begin to touch the central issue, but does indeed break a lot of
> things) demonstrate that *you* are not the guy to implement what was
> being discussed.  It needs to be done by someone who understands the
> core caching code, which apparently you haven't studied in any detail.

I didn't claim the attached patch began to touch the issues. I was very
clear that it covered only the very simplest use case, that was the
point. You may not wish to acknowledge it, but I *have* studied the core
caching code in detail for many months and that is the basis for my
comments. The way I have written the exclusions in vacuum.c shows that I
have identified each of the sub-cases we are required to handle.

There is nothing wrong with your idea of using a mapping file. That is
relatively easy part of the problem.

> I have a feeling that I should go do this...

If you wish, but I still think it is an unnecessary change for this
release, whoever does it. We both know that once you start you won't
stop, but that doesn't make it worthwhile or less risky.

 Simon Riggs 

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-01-31 20:13:55
Subject: Re: Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
Previous:From: Dimitri FontaineDate: 2010-01-31 19:55:36
Subject: Re: development setup and libdir

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group