From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "thomas(dot)munro(at)enterprisedb(dot)com" <thomas(dot)munro(at)enterprisedb(dot)com>, "tgarnett(at)panjiva(dot)com" <tgarnett(at)panjiva(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
Date: | 2015-04-27 15:24:41 |
Message-ID: | 20150427152441.GV4369@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Kevin Grittner wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Fri, Apr 24, 2015 at 5:34 PM, Kevin Grittner <kgrittn(at)ymail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-04-27 16:00:15 | Re: BUG #13143: Cannot stop and restart a streaming server with a replication slot |
Previous Message | Tom Lane | 2015-04-27 15:16:18 | Re: pg_get_constraintdef failing with cache lookup error |