Re: Online checksums patch - once again
От | Heikki Linnakangas |
---|---|
Тема | Re: Online checksums patch - once again |
Дата | |
Msg-id | b1fc5c97-2462-107e-2cc0-da09eb77daf3@iki.fi обсуждение исходный текст |
Ответ на | Re: Online checksums patch - once again (Daniel Gustafsson <daniel@yesql.se>) |
Ответы |
Re: Online checksums patch - once again
|
Список | pgsql-hackers |
Replying to an older message in this thread: >> + /* >> + * If we reach this point with checksums in inprogress state, we notify >> + * the user that they need to manually restart the process to enable >> + * checksums. This is because we cannot launch a dynamic background worker >> + * directly from here, it has to be launched from a regular backend. >> + */ >> + if (ControlFile->data_checksum_version == PG_DATA_CHECKSUM_INPROGRESS_VERSION) >> + ereport(WARNING, >> + (errmsg("checksum state is \"inprogress\" with no worker"), >> + errhint("Either disable or enable checksums by calling the >> pg_disable_data_checksums() or pg_enable_data_checksums() >> functions."))); >> >> This seems pretty half-baked. > > I don't disagree with that. However, given that enabling checksums is a pretty > intensive operation it seems somewhat unfriendly to automatically restart. As > a DBA I wouldn't want that to kick off without manual intervention, but there > is also the risk of this being missed due to assumptions that it would restart. > Any ideas on how to treat this? > > If/when we can restart the processing where it left off, without the need to go > over all data again, things might be different wrt the default action. The later patch version do support restarting, so I think we should revisit this issue. I would expect the checksums worker to be automatically started at postmaster startup. Can we make that happen? - Heikki
В списке pgsql-hackers по дате отправления: