Bruce Momjian <br...@momjian.us> writes: > Robert Haas wrote: >> I'm also curious to see how much more fallout we're going to see from >> that run. We had a few glitches when it was first done, but it didn't >> seem like they were really all that bad. It might be that we'd be >> better off running pgrminclude a lot *more* often (like once a cycle, >> or even after every CommitFest), because the scope of the changes >> would then be far smaller and we wouldn't be dealing with 5 years of >> accumulated cruft all at once; we'd also get a lot more experience >> with what works or does not work with the script, which might lead to >> improvements in that script on a less-than-geologic time scale.
> Interesting idea. pgrminclude has three main problems: [ snipped ] Actually, I believe that the *main* problem with pgrminclude is that it fails to account for combinations of build options other than those that Bruce uses. In the previous go-round, the reason we were still squashing bugs months later is that it took that long for people to notice and complain "hey, compiling with LOCK_DEBUG no longer works", or various other odd build options that the buildfarm doesn't exercise. I have 100% faith that we'll be squashing some bugs like that ... very possibly, the exact same ones as five years ago ... over the next few months. Peter's proposed tool would catch issues like the CppAsString2 failure, but it's still only going to exercise the build options you're testing with. If we could get pgrminclude up to a similar level of reliability as pgindent, I'd be for running it on every cycle. But I'm not sure that the current approach to it is capable even in theory of getting to "it just works" reliability. I'm also not impressed at all by the hack of avoiding problems by excluding entire files from the processing --- what's the point of having the tool then? > I think we determined that the best risk/reward is to run it every five > years. Frankly, with the tool in its current state I'd rather not run it at all, ever. The value per man-hour expended is too low. The mess it made out of the xlog-related includes this time around makes me question whether it's even a net benefit, regardless of whether it can be guaranteed not to break things. Fundamentally, there's a large component of design judgment/taste in the question of which header files should include which others, but this tool does not have any taste. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers