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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-patches by date

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