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
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? |