On Fri, Sep 9, 2011 at 11:28 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> It's very difficult or impossible to anticipate how effective the tool
> will be in practice, but when you consider that it works and does not
> produce false positives for the first 3 real-world cases tested, it
> seems reasonable to assume that it's at least worth having around. Tom
> recently said of a previous pgrminclude campaign in July 2006 that "It
> took us two weeks to mostly recover, but we were still dealing with
> some fallout in December". I think that makes the case for adding this
> tool or some refinement as a complement to pgrminclude in src/tools
> fairly compelling.
I'm not opposed to adding something like this, but I think it needs to
either be tied into the actual running of the script, or have a lot
more documentation than it does now, or both. I am possibly stupid,
but I can't understand from reading the script (or, honestly, the
thread) exactly what kind of pgrminclude-induced errors this is
protecting against; but even if we clarify that, it seems like it
would be a lot of work to run it manually on all the files that might
be affected by a pgrminclude run, unless we can somehow automate that.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
