Re: Rework the way multixact truncations work

On July 5, 2015 8:50:57 PM GMT+02:00, Robert Haas <robertmhaas@gmail.com> wrote:
>On Sun, Jul 5, 2015 at 2:28 PM, Andres Freund <andres@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 <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.
>
>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
primaryby 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*
todo 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.