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.
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 |