Re: [HACKERS] Checksums by default?
От | Stephen Frost |
---|---|
Тема | Re: [HACKERS] Checksums by default? |
Дата | |
Msg-id | 20170121183921.GQ18360@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Checksums by default? (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
* Andres Freund (andres@anarazel.de) wrote: > On 2017-01-21 13:03:52 -0500, Stephen Frost wrote: > > * Andres Freund (andres@anarazel.de) wrote: > > > On 2017-01-21 12:46:05 -0500, Stephen Frost wrote: > > > > Do you run with all defaults in those environments? > > > > > > Irrelevant - changing requires re-initdb'ing. That's unrealistic. > > > > I disagree. Further, we can add an option to be able to disable > > checksums without needing to re-initdb pretty trivially, which addresses > > the case where someone's having a problem because it's enabled, as > > discussed. > > Sure, it might be easy, but we don't have it. Personally I think > checksums just aren't even ready for prime time. If we had: > - ability to switch on/off at runtime (early patches for that have IIRC > been posted) > - *builtin* tooling to check checksums for everything > - *builtin* tooling to compute checksums after changing setting > - configurable background sweeps for checksums I'm certainly all for adding, well, all of that. I don't think we need *all* of it before considering enabling checksums by default, but I do think it'd be great if we had people working on adding those. > then the story would look differently. Right now checksums just aren't > particularly useful due to not having the above. Just checking recent > data doesn't really guarantee much - failures are more likely in old > data, and the data might even be read from ram. I agree that failures tend to be more likely in old data, though, as with everything, "it depends." Thanks! Stephen
В списке pgsql-hackers по дате отправления: