Re: Rework the way multixact truncations work

On Sun, Jul 5, 2015 at 2:28 PM, Andres Freund <andres(at)anarazel(dot)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(at)anarazel(dot)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