Re: Offline enabling/disabling of data checksums
От | Fabien COELHO |
---|---|
Тема | Re: Offline enabling/disabling of data checksums |
Дата | |
Msg-id | alpine.DEB.2.21.1903130713260.4059@lancre обсуждение исходный текст |
Ответ на | Re: Offline enabling/disabling of data checksums (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Offline enabling/disabling of data checksums
|
Список | pgsql-hackers |
Bonjour Michaël, > Yes, that would be nice, for now I have focused. For pg_resetwal yes > we could do it easily. Would you like to send a patch? I probably can do that before next Monday. I'll prioritize reviewing the latest instance of this patch, though. >> This seem contradictory to me: you want to disable checksum, and they are >> already disabled, so nothing is needed. How does that qualifies as a >> "failed" operation? > > If the operation is automated, then a proper reaction can be done if > multiple attempts are done. Of course, I am fine to tune things one > way or the other depending on the opinion of the crowd here. From the > opinions gathered, I can see that (Michael * 2) prefer failing with > exit(1), while (Fabien * 1) would like to just do exit(0). Yep, that sums it up:-). >> Indeed. I do not immediately see the use case where no syncing would be a >> good idea. I can see why it would be a bad idea. So I'm not sure of the >> concept. > > To leverage the buildfarm effort I think this one is worth it. Or we > finish to fsync the data folder a couple of times, which would make > the small-ish buildfarm machines suffer more than they need. Ok for the particular use-case, provided that the documentation is very clear about the risks, which is the case, so fine with me wrt to the feature. -- Fabien.
В списке pgsql-hackers по дате отправления: