Thread: Wraparound warning
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? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Tue, Oct 25, 2016 at 11:20 AM, Bruce Momjian <bruce@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. Maybe what we should do (since this message obviously annoys everyone) 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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@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? > Maybe what we should do (since this message obviously annoys everyone) It is a persistent reminder our of engineering failure. I guess it should annoy us, and maybe that's OK. > 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? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Tue, Oct 25, 2016 at 1:32 PM, Bruce Momjian <bruce@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 <bruce@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
On Tue, Oct 25, 2016 at 01:32:04PM -0400, Bruce Momjian 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@momjian.us> wrote: > > > LOG: MultiXact member wraparound protections are now enabled > > > > > > I thought that was going to be removed at some point, no? Latest proposal on when to remove it: https://www.postgresql.org/message-id/flat/CA%2BTgmobOoo9a9tGbvXgnvZC_p_15sVNHu2mV9usbB_OLGRZSmw%40mail.gmail.com Since we have outstanding multixact bugs, that proposal's clock of "a couple of years" has not begun to tick. > > Maybe what we should do (since this message obviously annoys everyone) > > It is a persistent reminder our of engineering failure. I guess it > should annoy us, and maybe that's OK. Yep. > > 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. I continue to find the message good as-is, per the thread I linked above.