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

Re: Hot Standby and VACUUM FULL

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hot Standby and VACUUM FULL
Date: 2010-01-31 19:00:08
Message-ID: 4B65D338.4050500@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Simon Riggs wrote:
> On Sat, 2010-01-30 at 15:17 -0500, Tom Lane wrote:
>> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>>> The last item on my list before close is making VACUUM FULL and Hot
>>> Standby play nicely together.
>>> The options to do this were and still are:
>>> (1) Add WAL messages for non-transactional relcache invalidations
>>> (2) Allow system relations to be cluster-ed/vacuum full-ed.
>>> (1) was how we did it originally and I believe it worked without
>>> problem. We saw the opportunity to do (2) and it has been worth
>>> exploring.
>> Refresh my memory on why (1) lets us avoid fixing (2)?  
> 
> (1) allows us to retain VACUUM FULL INPLACE for system relations, thus
> avoiding the need to do (2). Non-transactional invalidations need to be
> replayed in recovery for the same reason they exist on the primary.
> 
>> It sounds like a kluge at best ...
> 
> (2) isn't a necessary change right now. It is the best design going
> forwards, but its burst radius stretches far beyond Hot Standby. There
> is enough code in HS for us to support, so adding to it makes little
> sense for me, in this release, since there is no functional benefit in
> doing so.

Well, it'll avoid having to support the kludges in HS required for
VACUUM FULL INPLACE.

I'm in favor of (2), unless some unforeseen hard problems come up with
implementing the ideas on that discussed earlier. Yeah, that's pretty
vague, but basically I think it's worth spending some more time doing
(2), than doing (1). For one, if the plan is to do (2) in next release
anyway, we might as well do it now and avoid having to support the
HS+VACUUM FULL INPLACE combination in only 9.0 stable branch for years
to come.

I believe we had a pretty well-thought out plan on how to support system
catalogs with the new VACUUM FULL.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-01-31 19:07:47
Subject: Re: Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
Previous:From: Tom LaneDate: 2010-01-31 18:26:07
Subject: Re: Memory leak in deferrable index constraints

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