On Tue, Oct 25, 2016 at 1:32 PM, Bruce Momjian <br...@momjian.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 <br...@momjian.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers