| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Timothy Garnett <tgarnett(at)panjiva(dot)com>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
| Date: | 2015-05-07 18:39:50 |
| Message-ID: | 20150507183950.GH2523@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Robert Haas wrote:
> On Thu, May 7, 2015 at 2:00 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> > I considered this question in the previous commit: is it okay to
> > overwrite a file that is no longer used (per the limits set by vacuum)
> > but not yet removed (by checkpoint)? It seems to me that there is no
> > data-loss issue with doing that -- which is why the advance-oldest code
> > is called during vacuum and not during checkpoint.
>
> I think the main question is whether truncation will be smart enough
> to zap the non-overwritten part of the old stuff but not the part that
> did get overwritten.
TruncateMultiXact bases its removal of member files on the point set by
checkpoint, MultiXactState->lastCheckpointedOldest. I tested this back
then and there was no issue.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2015-05-07 20:32:53 | Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
| Previous Message | Robert Haas | 2015-05-07 18:32:51 | Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |