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

Re: [WIP] Add relminxid column to pg_class

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [WIP] Add relminxid column to pg_class
Date: 2006-04-10 02:26:12
Message-ID: 15670.1144635972@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
[ dept of further thoughts ]

I wrote:
>> 4. VACUUM has to recompute datminxid to be the oldest non-frozen
>> relminxid in the database (but not more than transaction xmin, to cover
>> case where someone else is creating a table concurrently).

Strictly speaking, VACUUM could never set datminxid = FrozenXid given
the above rule --- and this is correct, because someone else could be
creating a new table or unfreezing an existing table concurrently with
the VACUUM.  However, we'd really like to set datminxid = FrozenXid for
template0, because otherwise we can't write any sort of hardline
guarantee that we know the database system is safe against wraparound.

I see a workaround though: it *is* OK for VACUUM FREEZE to set datminxid
= FrozenXid if (1) it's been able to freeze all the tables and (2) it's
running in a standalone backend.  This rule would let us freeze
template0 during initdb.

There's still a question of where/when to worry about marking a database
unfrozen.  Perhaps a suitably cheap, conservative approximation would be
to cause any new connection to a frozen database to immediately mark it
unfrozen in pg_database.  (I'm not sure if this works conveniently for
initdb's processing though --- we might want to fudge a bit depending on
whether we're running standalone.)

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2006-04-10 03:57:11
Subject: Re: [WIP] Add relminxid column to pg_class
Previous:From: Joshua D. DrakeDate: 2006-04-10 01:07:58
Subject: Re: Suggestion: Which Binary?

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