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

Re: pgsql: Create a "relation mapping" infrastructure to support changing

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)postgresql(dot)org>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Create a "relation mapping" infrastructure to support changing
Date: 2010-02-07 22:29:17
Message-ID: 1265581757.27207.202.camel@ebony (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Sun, 2010-02-07 at 20:48 +0000, Tom Lane wrote:
> Log Message:
> -----------
> Create a "relation mapping" infrastructure to support changing the relfilenodes
> of shared or nailed system catalogs.  This has two key benefits:
> 
> * The new CLUSTER-based VACUUM FULL can be applied safely to all catalogs.
> 
> * We no longer have to use an unsafe reindex-in-place approach for reindexing
>   shared catalogs.
> 
> CLUSTER on nailed catalogs now works too, although I left it disabled on
> shared catalogs because the resulting pg_index.indisclustered update would
> only be visible in one database.
> 
> Since reindexing shared system catalogs is now fully transactional and
> crash-safe, the former special cases in REINDEX behavior have been removed;
> shared catalogs are treated the same as non-shared.
> 
> This commit does not do anything about the recently-discussed problem of
> deadlocks between VACUUM FULL/CLUSTER on a system catalog and other
> concurrent queries; will address that in a separate patch.  As a stopgap,
> parallel_schedule has been tweaked to run vacuum.sql by itself, to avoid
> such failures during the regression tests.

Awesome!


Few questions:

We XLogFlush() in normal running, but not in recovery. Would it be
possible for the map changes to hit disk after the data changes in that
case?

What we're saying is if we process a relmap update WAL record then it
doesn't really matter whether or not we commit that transaction?

>         func.sgml (r1.500 -> r1.501)
>         (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/func.sgml?r1=1.500&r2=1.501)

It would be useful to mention that the return value is volatile and can
change across transactions or even within a transaction, just like ctid.

>         catalogs.sgml (r2.220 -> r2.221)
>         (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/catalogs.sgml?r1=2.220&r2=2.221)

No mention of pg_relation_filepath/filenode in there.

-- 
 Simon Riggs           www.2ndQuadrant.com


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-02-07 22:52:02
Subject: Re: pgsql: Create a "relation mapping" infrastructure to support changing
Previous:From: Gokulakannan SomasundaramDate: 2010-02-07 22:22:26
Subject: Re: Precedence of Postfix operators

pgsql-committers by date

Next:From: Tom LaneDate: 2010-02-07 22:40:33
Subject: pgsql: Work around deadlock problems with VACUUM FULL/CLUSTER on system
Previous:From: Tom LaneDate: 2010-02-07 22:00:53
Subject: pgsql: Looks like we need #include <sys/stat.h> here on some platforms.

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