Ühel kenal päeval, E, 2006-05-15 kell 17:21, kirjutas Tom Lane:
> Hannu Krosing <hannu@skype.net> writes:
> >> Sven Suursoho wrote:
> >>> As for testing in actual pl/python build environment, we had objections from
> >>> leading postgresql Tom Lane that even if we do test it at build time,
> >>> a determined DBA may substitute a buggy python.so later and still crash her DB instance.
>
> The above is a straw-man depiction of my point.
Sure ;)
> What I said was that just
> because python is up-to-date on the system where plpython is *compiled*
> does not mean it'll be up-to-date on the system where plpython is *used*.
Would running an external program at pl init time and testing for its
crash status be a good broken lib test for plpython ?
> With the increasing popularity of prebuilt packages (rpm, deb, etc),
> I think it's folly to use a build-time check for this.
I guess most packaging systems can require some minimal version of
dependencies.
And in general newer versions are less buggy than old ones.
So i guess that some combination of build-time/run-time tests,
documentation and packager education should take care of 99% of
concerns ?
Hopefully we can just ignore the "determined DBA" failure mode and move
forward with including the patch. Or do you think that trying to hack in
the extra python frame to all/some builds to ward of potentially broken
libs would still be something to go for ?
--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
NOTICE: This communication contains privileged or other confidential
information. If you have received it in error, please advise the sender
by reply email and immediately delete the message and any attachments
without copying or disclosing the contents.
