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, whole thread or download thread mbox)
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.


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

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)
>         (

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)
>         (

No mention of pg_relation_filepath/filenode in there.

 Simon Riggs 

In response to


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-2017 The PostgreSQL Global Development Group