Re: Rework the way multixact truncations work

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rework the way multixact truncations work
Date: 2015-07-05 19:16:52
Message-ID: 76BAE7CE-1B72-4A06-816F-996FACBDFE07@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On July 5, 2015 8:50:57 PM GMT+02:00, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>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.

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2015-07-05 19:25:56 Re: dblink: add polymorphic functions.
Previous Message Robert Haas 2015-07-05 18:50:57 Re: Rework the way multixact truncations work