* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost <sfr...@snowman.net> writes:
> > As for checksums, I do see value in them and I'm pretty sure that the
> > author of that particular feature did as well, or we wouldn't even have
> > it as an option.  You seem to be of the opinion that we might as well
> > just rip all of that code and work out as being useless.
> Not at all; I just think that it's not clear that they are a net win
> for the average user, and so I'm unconvinced that turning them on by
> default is a good idea.  I could be convinced otherwise by suitable
> evidence.  What I'm objecting to is turning them on without making
> any effort to collect such evidence.

> Also, if we do decide to do that, there's the question of timing.
> As I mentioned, one of the chief risks I see is the possibility of
> false-positive checksum failures due to bugs; I think that code has seen
> sufficiently little field use that we should have little confidence that
> no such bugs remain.  So if we're gonna do it, I'd prefer to do it at the
> very start of a devel cycle, so as to have the greatest opportunity to
> find bugs before we ship the new default.

I can agree with a goal to make sure we aren't enabling code that a
bunch of people are going to be seeing false positives due to, as that
would certainly be bad.  I also agree that further testing is generally
a good idea, I just dislike the idea that we would prevent this change
to the default due to performance concerns of a few percent in a default

I'll ask around with some of the big PG installed bases (RDS, Heroku,
etc) and see if they're a) enabling checksums already (and therefore
doing a lot of testing of those code paths), and b) if they are, if
they have seen any true or false positive reports from it.

If we hear back that the large installed bases in those environments are
already running with checksums enabled, without issues, then I'm not
sure that we need to wait until the start of the next devel cycle to
change the default.  Alternativly, if we end up wanting to change the
on-disk format, as discussed elsewhere on this thread, then we might
want to wait and make that change at the same time as a change to the
default, or at least not change the default right before we decide to
change the format.



Attachment: signature.asc
Description: Digital signature

Reply via email to