Re: Hot Standby, release candidate? - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Hot Standby, release candidate?
Date
Msg-id 1260816034.1955.1454.camel@ebony
Whole thread Raw
In response to Re: Hot Standby, release candidate?  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Hot Standby, release candidate?
List pgsql-hackers
On Sun, 2009-12-13 at 22:25 +0000, Simon Riggs wrote:

> * Which exact tables are we talking about: just pg_class and the shared
> catalogs? Everything else is in pg_class, so if we can find it we're OK?
> formrdesc() tells me the list of nailed relations is: pg_database,
> pg_class, pg_attribute, pg_proc, and pg_type. Are the nailed relations
> the ones we care about, or are they just a subset? 

Comments in cluster.c's check_index_is_clusterable() suggest that the
list of tables to which this applies is nailed relations *and* shared
relations, plus their indexes.

/** Disallow clustering system relations.  This will definitely NOT work* for shared relations (we have no way to
updatepg_class rows in other* databases), nor for nailed-in-cache relations (the relfilenode values* for those are
hardwired,see relcache.c).  It might work for other* system relations, but I ain't gonna risk it.*/
 

So that means we need to handle 3 cases: nailed-local, nailed-shared and
non-nailed-shared.

I would presume we would not want to relax the restriction on CLUSTER
working on these tables, even if new VACUUM FULL does.

Anyway, not going to be done for Alpha3, but seems fairly doable now.

-- Simon Riggs           www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Hot Standby, release candidate?
Next
From: Peter Eisentraut
Date:
Subject: Re: Python 3.1 support