(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 <andres@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.
> >> The checkpoint hasn't really happened at that point yet; you might
> >> truncate away stuff, then crash before the checkpoint is complete, and
> >> then we you restart recovery, you've got trouble.
> >
> > We're only talking about restartpoints here, right? And I don't see the
> > problem - we don't read the slru anymore until the end of recovery, and
> > the end of recovery can't happen before reaching the minimum revovery
> > location?
>
> You're still going to have to read the SLRU for as long as you are
> doing legacy truncations, at least.
I'm not following. Sure, we read the SLRUs as we do today. But, in
contrast to the current positioning in recovery, with the patch they're
done at pretty much the same point on the standby as on the primary
today?
Greetings,
Andres Freund