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

Re: [WIP] Add relminxid column to pg_class

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [WIP] Add relminxid column to pg_class
Date: 2006-04-09 18:33:13
Message-ID: 20060409183312.GA15094@surnet.cl (view raw or flat)
Thread:
Lists: pgsql-patches
Tom Lane wrote:

> I'd argue that you should do nothing, ie, dropping a table should never
> affect datminxid.  The proper interpretation of the pg_database columns
> is that we guarantee that all XID's in the database are *at least* thus-
> and-so, not that the minimum is exact.

Ok, this new patch does this.  It allowed to simplify some code a bit,
and works wonderfully.

However I spotted another problem.  Suppose I initdb; then I use the
system for some 2 billion-minus-delta transactions.  At this point, I
create a new database using template0 as template.  When this is done,
the logic in createdb() puts the current TransactionId as
pg_database.datminxid and datvacuumxid, which is fine because we assume
that template0 is fully frozen and thus it doesn't need vacuuming right
away.

However, pg_class entries all contain values close to 500 (the Xid at
which the initial vacuum is run by initdb).  Thus if you vacuum only one
table, the cluster-wide limit will be set at that low value, and
suddenly the server will refuse to generate TransactionIds; the user
will be forced to start a standalone postgres to vacuum.

The solution seems to be to vacuum the whole database right after
cloning.  Or to forcibly set the pg_class value to the current
TransactionId, without vacuuming (which should be fine, because the
template database was frozen).

Thoughts?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2006-04-09 18:39:41
Subject: Re: Support Parallel Query Execution in Executor
Previous:From: Gregory MaxwellDate: 2006-04-09 18:18:04
Subject: Re: Support Parallel Query Execution in Executor

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