On Sun, Jul 5, 2015 at 2:28 PM, Andres Freund <and...@anarazel.de> wrote: > (quick answer, off now) > > On 2015-07-05 14:20:11 -0400, Robert Haas wrote: >> On Thu, Jul 2, 2015 at 2:28 PM, Andres Freund <and...@anarazel.de> wrote: >> > On 2015-07-02 13:58:45 -0400, Robert Haas wrote: >> >> I seriously, seriously doubt that it is a good idea to perform the >> >> legacy truncation from MultiXactAdvanceOldest() rather than >> >> TruncateMultiXact(). >> > >> > But where should TruncateMultiXact() be called from? I mean, we could >> > move the logic from inside MultiXactAdvanceOldest() to some special case >> > in the replay routine, but what'd be the advantage? >> >> I think you should call it from where TruncateMultiXact() is being >> called from today. Doing legacy truncations from a different place >> than we're currently doing them just gives us more ways to be wrong. > > The problem with that is that the current location is just plain > wrong. Restartpoints can be skipped (due different checkpoint segments > settings), may not happen at all (pending incomplete actions), and can > just be slowed down. > > That's a currently existing bug that's easy to reproduce.
You might be right; I haven't tested that. On the other hand, in the common case, by the time we perform a restartpoint, we're consistent: I think the main exception to that is if we do a base backup that spans multiple checkpoints. I think that in the new location, the chances that the legacy truncation is trying to read inconsistent data is probably higher. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
