Re: Offline enabling/disabling of data checksums
От | Michael Paquier |
---|---|
Тема | Re: Offline enabling/disabling of data checksums |
Дата | |
Msg-id | 20190315025027.GN3493@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Offline enabling/disabling of data checksums (Michael Banck <michael.banck@credativ.de>) |
Ответы |
Re: Offline enabling/disabling of data checksums
Re: Offline enabling/disabling of data checksums Re: Offline enabling/disabling of data checksums |
Список | pgsql-hackers |
On Thu, Mar 14, 2019 at 04:26:20PM +0100, Michael Banck wrote: > Am Donnerstag, den 14.03.2019, 15:26 +0100 schrieb Magnus Hagander: >> One big-hammer method could be similar to what pg_upgrade does -- >> temporarily rename away the controlfile so postgresql can't start, and >> when done, put it back. > > That sounds like a good solution to me. I've made PoC patch for that, > see attached. Indeed. I did not know this trick from pg_upgrade. We could just use the same. > The only question is whether pg_checksums should try to move pg_control > back (i) on failure (ii) when interrupted? Yes, we should have a callback on SIGINT and SIGTERM here which just moves back in place the control file if the temporary one exists. I have been able to grab some time to incorporate the feedback gathered on this thread, and please find attached a new version of the patch to add --enable/--disable. The main changes are: - When enabling checksums, fsync first the data directory, and at the end then update/flush the control file and its parent folder as Fabien has reported. - When disabling checksums, only work on the control file, as Fabien has also reported. - Rename the control file when beginning the enabling operation, with a callback to rename the file back if the operation is interrupted. Does this make sense? -- Michael
Вложения
В списке pgsql-hackers по дате отправления: