Re: [WIP] Add relminxid column to pg_class
От | Tom Lane |
---|---|
Тема | Re: [WIP] Add relminxid column to pg_class |
Дата | |
Msg-id | 15670.1144635972@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [WIP] Add relminxid column to pg_class (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: [WIP] Add relminxid column to pg_class
|
Список | 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
В списке pgsql-patches по дате отправления: