Ühel kenal päeval, E, 2006-05-15 kell 17:21, kirjutas Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> 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

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.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to