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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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.
Attachment | Content-Type | Size |
---|---|---|
relminxid-2.patch | text/plain | 72.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-04-09 18:39:41 | Re: Support Parallel Query Execution in Executor |
Previous Message | Gregory Maxwell | 2006-04-09 18:18:04 | Re: Support Parallel Query Execution in Executor |