> AFAICS there are no circumstances, ever, in which update-in-place is > "safe". (No transaction can guarantee that it will commit.)
In our case, it is totally safe. I'd certainly like to discuss it with you sometime at the anniversary. > Martin's proposal at least looks sensible; he just hasn't quite made the > case that it's worth doing ... I agree that it likely would never be the > default. But it could be a good tradeoff for some cases. I guess I can think of a few instances, but none that I would've chosen to use it in. IIRC, it's also more likely to increase the cost of checkpointing and/or require a good amount of bgwriter tuning. As long as it's optional, I guess it's OK to let the administrator deal with recovery. Of course, in addition to no-fsync, we'll have another *possibly* dangerous option. BTW, I've seen no-fsync used far too many times because people think they're hardware is invincible. My only suggestion is to make sure it's a very well documented option. -- Jonah H. Harris, Database Internals Architect EnterpriseDB Corporation 732.331.1324 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
