Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)
От | Robert Haas |
---|---|
Тема | Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
Дата | |
Msg-id | CA+Tgmoab0NnxOWBbALAfqJFr7x=vt8BxXKDGiFbU6JRf8mszSQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Re: BUG #12990: Missing pg_multixact/members files
(appears to have wrapped, then truncated)
|
Список | pgsql-bugs |
On Thu, May 7, 2015 at 2:00 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Robert Haas wrote: >> It seems to me that the most obvious places where >> DetermineSafeOldestOffset() should be called are (1) at startup or >> after recovery, to initialize the value; and (2) each time we truncate >> the SLRU, to update the value. Other than that, this doesn't change. >> The startup calls are there, in apparently reasonable places, but it's >> not obvious to me how this gets called in the TruncateMultiXact path. >> Instead it seems to get set via the SetMultiXactIdLimit path. Maybe >> that's OK, but it would seem to imply that we're OK with overwriting >> old members information if that information was slated for truncation >> at the next checkpoint anyway, which seems scary. > > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-bugs по дате отправления: