[ 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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to