Re: PL/Python fails on new NetBSD/PPC 8.0 install

[Benjamin Scherrey]

None of the output provides any clue to me but I do know that Python 3.7
has some issues with a lot of versions of openssl that is based on a
disagreement between devs in both projects. This was a problem for me when
trying to build python 3.7 on my Kubuntu 14.04 system. I've seen this issue
reported across all targets for Python including Freebsd so I expect it's
likely to also happen for NetBSD.

Perhaps this might be related to the problem?

On Mon, Oct 28, 2019, 8:12 AM Tom Lane  wrote:

> Awhile back I wrote:
> > I noticed that the old NetBSD 5.1.5 installation I had on my G4 Mac
> > was no longer passing our regression tests, because it has a strtof()
> > that is sloppy about underflow.  Rather than fight with that I decided
> > to update it to something shinier (well, as shiny as you can get on
> > hardware that's old enough to apply for a driver's license).  I stuck in
> > NetBSD/macppc 8.0, and things seem to work, except that PL/Python
> > crashes on launch.  I see something like this in the postmaster log:
>
> > Traceback (most recent call last):
> >   File "", line 1162, in
> _install_external_importers
> >   File "", line 980, in _find_and_load
> >   File "", line 149, in __enter__
> >   File "", line 84, in acquire
> > RuntimeError: no current thread ident
> > Fatal Python error: initexternalimport: external importer setup failed
> >
> > Current thread 0x (most recent call first):
> > 2019-06-18 17:40:59.629 EDT [20764] LOG:  server process (PID 23714) was
> terminated by signal 6: Abort trap
> > 2019-06-18 17:40:59.629 EDT [20764] DETAIL:  Failed process was running:
> CREATE FUNCTION stupid() RETURNS text AS 'return "zarkon"' LANGUAGE
> plpython3u;
>
> So ... I just got this identical failure on NetBSD 8.1 on a shiny
> new Intel NUC box.  So that removes the excuse of old unsupported
> hardware, and leaves us with the conclusion that PL/Python is
> flat out broken on recent NetBSD.
>
> This is with today's HEAD of our code and the python37-3.7.4/amd64
> package from NetBSD 8.1.
>
> BTW, the only somewhat-modern NetBSD machine in our buildfarm is
> coypu, which is running NetBSD/macppc 8.0 ... but what it is testing
> PL/Python against is python 2.7.15, so the fact that it doesn't
> fail can probably be explained as a python 2 vs python 3 thing.
>
> regards, tom lane
>
>
>

Re: How can we submit code patches that implement our (pending) patents?

[Benjamin Scherrey]

On Wed, Jul 25, 2018 at 12:56 PM, Nico Williams 
wrote:

> On Tue, Jul 24, 2018 at 06:29:37PM -0400, Isaac Morland wrote:
> > On 24 July 2018 at 18:17, Nico Williams  wrote:
> > > Note that it's OK to *accidentally* implement patented algorithms as
> > > long as the author of the contribution didn't know about.  There's no
> > > trebble damages in that case, and no tainting of others, plus,
> > > contributors and code reviewers/committers can't be expected to do
> > > patent searches for each contribution.
> >
> > Non-lawyer here, but "OK" is not a description I would apply to
> > implementing a patented algorithm. You might be thinking of copyright. Of
> > course it is true that people can't reasonably be expected to do patent
> > searches, as you describe, but the patent system as applied to software
> is
> > not well-known among knowledgeable people for being reasonable.
>
> Wrong.  With patents the important thing is not to know about them when
> you implement -- if you come up with the same idea by accident (which,
> of course, is obviously entirely possible) then you are not subject to
> trebble damages.  But if you knowingly copy the invention without a
> license then you are subject to trebble damages.
>
> A lot of patented ideas are fairly obvious.  That always seems true
> after the fact, naturally, but many are fairly obvious even before
> knowing about them.  It's clearly possible that you'll infringe by
> accident -- that's OK by comparison to infringing on purpose.
>
> Nico
> --
>

If you violate a patent, knowingly or otherwise, you are subject to
penalties (perhaps not treble but still penalties) and will have to remove
the offending code unless a deal is reached with the patent holder.

It is critical that Postgres require that all contributors do not enforce
patents against Postgres - full stop. That's the IP agreement that should
be in place.

  -- Ben Scherrey