Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)
От | Alvaro Herrera |
---|---|
Тема | Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
Дата | |
Msg-id | 20150427152441.GV4369@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) (Kevin Grittner <kgrittn@ymail.com>) |
Список | pgsql-bugs |
Kevin Grittner wrote: > Robert Haas <robertmhaas@gmail.com> wrote: > > On Fri, Apr 24, 2015 at 5:34 PM, Kevin Grittner <kgrittn@ymail.com> wrote: > >> I think I see why I was seeing this and nobody else was > > > > Thomas said he reproduced it. No? > > I should have been more clear about what I meant by "this". Thomas > said he reproduced the immediate errors with Álvaro's patch, but if > he said anything about files in the members subdirectory not going > away with VACUUM followed by CHECKPOINT, regardless of > configuration, I missed it. It turns out that these steps only > "prime the pump" for the files to be deleted on subsequent access > to the members SLRU. That doesn't contribute to database > corruption, but it sure can be confusing for someone trying to > clean things up. The whole matter of truncating multixact is a longish trip. It starts when autovacuum completes a round or VACUUM finishes processing a table; these things call vac_update_datfrozenxid. That routine scans pg_class and sees if datfrozenxid or datminmxid can be advanced from their current points; only if any of these can, vac_truncate_clog is called. That routine calls SetMultiXactIdLimit(), which determines a new MultiXactState->oldestMultiXactId (saved in shared memory). The involvement of vacuum stops here; following steps happen at checkpoint. At checkpoint, oldestMultiXactId is saved to pg_control as part of a checkpoint (MultiXactGetCheckptMulti); the checkpointed value is passed back to multixact by MultiXactSetSafeTruncate, which saves it in shmem as lastCheckpointedOldest. The same checkpoint later calls TruncateMultiXact which can remove files. Note that if vac_update_datfrozenxid finds that the pg_database values cannot be changed (during the vacuum phase), the multixact truncation point is not advanced and checkpoint has nothing to do. But note that the clog counter advancing enough will also trigger multixact truncation. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-bugs по дате отправления: