Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)

On Sun, May 10, 2015 at 9:41 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Sun, May 10, 2015 at 12:43 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> OK. So the next question is: if you then apply the other patch, does that prevent step 4 and thereby avoid catastrophe?
>
> Yes, in a quick test, at step 4 I couldn't proceed. I need to prod
> this some more on Monday, and also see how it interacts with
> autovacuum's view of what work needs to be done.

The code in master which handles regular autovacuums seems correct
with this patch, because it measures member space usage by calling
find_multixact_start itself with the oldest multixact ID (it's not
dependent on anything that is updated at checkpoint time).

The code in the patch at
http://www.postgresql.org/message-id/CA+TgmobbaQpE6sNqT30+rz4UMH5aPraq20gko5xd2ZGajz1-Jg@mail.gmail.com
would become wrong though, because it would use the (new) variable
MultiXactState->oldestOffset (set at checkpoint) to measure the used
member space. That means it would repeatedly launch autovacuums, even
after clearing away the problem and advancing the oldest multixact ID,
until the next checkpoint updates that value. In other words, it
can't see its own progress immediately (which is the right approach
for blocking new multixact generation, ie defer until
checkpoint/truncation, but the wrong approach for triggering
autovacuums).

I think vacuum (SetMultiXactIdLimit?) needs to update oldestOffset,
not checkpoint (DetermineSafeOldestOffset). (The reason for wanting
this new value in shared memory is because GetNextMultiXactId needs to
be able to check it cheaply for every call, so calling
find_multixact_start every time would presumably not fly).

--
Thomas Munro
http://www.enterprisedb.com