On July 5, 2015 8:50:57 PM GMT+02:00, Robert Haas <robertmh...@gmail.com> wrote: >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.
The primary problem isn't that we truncate too early, it's that we delay truncation on the standby in comparison to the primary by a considerable amount. All the while continuing to replay multi creations. I don't see the difference wrt. consistency right now, but I don't have access to the code right now. I mean we *have* to do something while inconsistent. A start/stop backup can easily span a day or four. Andres --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
