From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jan Urbański <wulczer(at)wulczer(dot)org> |
Subject: | Re: Large C files |
Date: | 2011-09-23 14:46:00 |
Message-ID: | CA+TgmoYOTkPi-Ntf94v2Z1iLyFyaVbKBCxYf9Vp-DwFDHKeC8Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 9, 2011 at 11:28 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2011-09-23 14:53:52 | Re: DECLARE CURSOR must not contain data-modifying statements in WITH |
Previous Message | Alvaro Herrera | 2011-09-23 14:44:09 | Re: Re: [BUGS] BUG #6189: libpq: sslmode=require verifies server certificate if root.crt is present |