Re: Wraparound warning

On Tue, Oct 25, 2016 at 1:32 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Tue, Oct 25, 2016 at 01:19:26PM -0400, Robert Haas wrote:
>> On Tue, Oct 25, 2016 at 11:20 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> > Do we still need to report the wraparound warning on server startup?
>> >
>> > LOG: MultiXact member wraparound protections are now enabled
>> >
>> > I thought that was going to be removed at some point, no?
>>
>> If you start with a 9.3.small cluster and do a pg_upgrade to 10, you
>> could end up not seeing that message and not having those protections
>> enabled, and it would be useful to be able to tell that from looking
>> at the log.
>
> Uh, I am confused. I am seeing this on a fresh PG 10 initdb'ed cluster,
> not one pg_upgraded. Is that expected?

Yes, that is expected. If you initdb with a version >= 9.5, you will
always see that message on every startup. However, if you initdb with
an older version, things get messed up, and then you pg_upgrade, you
might fail to see it. Not seeing it would indicate that your cluster
is in a bad situation, which is something you might want to know
about.

>> is change things so that, starting in v10, a message is logged at
>> startup if those protections are NOT enabled, and nothing is logged if
>> they are enabled. Keep the message for the case where protections are
>> enabled later, after startup time.
>
> How are those protections enabled/disabled?

When you start the cluster, they are disabled. We then try to enable
them every time SetOffsetVacuumLimit() is called. It tries to
determine the oldest multixact offset by examining what it thinks is
the oldest multixact. If that works, then it enables the protections.
If that fails because the "oldest multixact" value is corrupted and
that multixact doesn't actually exist, then it forces autovacuum to
run in emergency mode, which will eventually correct the problem.
Once the problem has been corrected, the next call to
SetOffsetVacuumLimit() will enable the protections.

Normally, your cluster is OK, so the very first call to that function
enables the protections right at startup time. Maybe we should skip
emitting the message in that case, so that the "normal" case doesn't
generate extra log chatter.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company