Обсуждение: uuid-ossp (Re: [pgsql-packagers] Postgresapp 9.4 beta build ready)
[redirecting to -hackers]
Re: Tom Lane 2014-05-15 <31008.1400180005@sss.pgh.pa.us>
> Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> writes:
> > Yes, Jakob is right. On 9.4, we had to patch configure script along with
> > uuid-ossp.c to resolve the uuid issue.
>
> I think we need to discuss this on the open pgsql-hackers list.
> It seems like we have to either
>
> (1) hack both configure and uuid-ossp.c to work around the issue
>
> (2) do something more radical, like adopt Palle's patch to use the
> BSD uuid functions.
>
> Now, (2) sounds a bit scary for a post-beta1 change, but on the other hand
> we know that ossp-uuid is a train wreck in progress. Maybe it's time
> to do something about it. But that's got to be debated on -hackers not
> here.
Fwiw, libossp-uuid is the only non-trivial dependency of
postgresql*.{deb,rpm} - I've been to trainings at customer sites more
than once where we just had a preinstalled Linux machine with no
internet and a set of PostgreSQL packages that needed dpkg
--force-depends or rpm --nodeps to install just because the -contrib
package needs that lib.
So if we got rid of that dependency, life might become a bit easier
also in that setting.
Christoph
--
cb@df7cb.de | http://www.df7cb.de/
Christoph Berg <cb@df7cb.de> writes:
> [redirecting to -hackers]
> Re: Tom Lane 2014-05-15 <31008.1400180005@sss.pgh.pa.us>
>> Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> writes:
>>> Yes, Jakob is right. On 9.4, we had to patch configure script along with
>>> uuid-ossp.c to resolve the uuid issue.
>> I think we need to discuss this on the open pgsql-hackers list.
>> It seems like we have to either
>>
>> (1) hack both configure and uuid-ossp.c to work around the issue
>>
>> (2) do something more radical, like adopt Palle's patch to use the
>> BSD uuid functions.
>>
>> Now, (2) sounds a bit scary for a post-beta1 change, but on the other hand
>> we know that ossp-uuid is a train wreck in progress. Maybe it's time
>> to do something about it. But that's got to be debated on -hackers not
>> here.
> Fwiw, libossp-uuid is the only non-trivial dependency of
> postgresql*.{deb,rpm} - I've been to trainings at customer sites more
> than once where we just had a preinstalled Linux machine with no
> internet and a set of PostgreSQL packages that needed dpkg
> --force-depends or rpm --nodeps to install just because the -contrib
> package needs that lib.
> So if we got rid of that dependency, life might become a bit easier
> also in that setting.
I was intending to draft something more self-contained to present to
-hackers, but since this is where we're at ... the quoted material
omits a couple of important points:
(1) People had been working around uuid-ossp's issues on OS X by
patching a "#define _XOPEN_SOURCE" into contrib/uuid-ossp/uuid-ossp.c.
As of 9.4 this is no longer sufficient because we upgraded to autoconf
2.69, which uses stricter testing for include-file validity than older
versions did. The test to see if uuid.h is available therefore fails,
unless that #define is also patched into the configure script. In any
case "#define _XOPEN_SOURCE" has enough potential implications that
this doesn't seem like a very recommendable solution.
(2) "Palle's patch" mentioned above can be seen here:
http://svnweb.freebsd.org/ports/head/databases/postgresql93-server/files/patch-contrib-uuid?revision=348732&view=markup
Basically it jacks up contrib/uuid-ossp and rolls the BSD uuid functions
underneath. It looks like this is based on work by Andrew Gierth.
So, having seen that proof-of-concept, I'm wondering if we shouldn't make
an effort to support contrib/uuid-ossp with a choice of UUID libraries
underneath it. There is a non-OSSP set of UUID library functions
available on Linux ("libuuid" from util-linux-ng). I don't know whether
that's at all compatible with the BSD functions, but even if it's not,
presumably a shim for it wouldn't be much larger than the BSD patch.
A bigger question is whether there are any user-visible functional
incompatibilities introduced by depending on either of those libraries
instead of OSSP uuid. Some research would be needed.
It's not exactly appetizing to consider fooling around with such changes
post-beta1. But on the other hand, OSSP uuid *is* a train wreck in
progress, and remaining dependent on it for another release cycle is not
exactly appetizing either.
Comments? Is anybody feeling motivated to do the legwork on this?
regards, tom lane
On 5/18/14, 12:28 AM, Tom Lane wrote:
> So, having seen that proof-of-concept, I'm wondering if we shouldn't make
> an effort to support contrib/uuid-ossp with a choice of UUID libraries
> underneath it. There is a non-OSSP set of UUID library functions
> available on Linux ("libuuid" from util-linux-ng). I don't know whether
> that's at all compatible with the BSD functions, but even if it's not,
> presumably a shim for it wouldn't be much larger than the BSD patch.
I was going to propose based on earlier discussion that we would stick a
deprecation notice on uuid-ossp and leave it at that.
Between pgcrypto and https://github.com/petere/pglibuuid, there are
other options available. Writing wrapper functions for backward
compatibility is trivial for users.
> A bigger question is whether there are any user-visible functional
> incompatibilities introduced by depending on either of those libraries
> instead of OSSP uuid. Some research would be needed.
You might need to make sure your random sources are set up
appropriately, and that might differ between libraries. And libuuid
recommends the use of the uuidd daemon in some circumstances. These are
arguments, in my mind, for not providing compatibility wrappers by
default, so that these issues don't get hidden.
On Sun, May 18, 2014 at 12:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I was intending to draft something more self-contained to present to > -hackers, but since this is where we're at ... the quoted material > omits a couple of important points: > > (1) People had been working around uuid-ossp's issues on OS X by > patching a "#define _XOPEN_SOURCE" into contrib/uuid-ossp/uuid-ossp.c. > As of 9.4 this is no longer sufficient because we upgraded to autoconf > 2.69, which uses stricter testing for include-file validity than older > versions did. The test to see if uuid.h is available therefore fails, > unless that #define is also patched into the configure script. In any > case "#define _XOPEN_SOURCE" has enough potential implications that > this doesn't seem like a very recommendable solution. > > (2) "Palle's patch" mentioned above can be seen here: > http://svnweb.freebsd.org/ports/head/databases/postgresql93-server/files/patch-contrib-uuid?revision=348732&view=markup > Basically it jacks up contrib/uuid-ossp and rolls the BSD uuid functions > underneath. It looks like this is based on work by Andrew Gierth. > > So, having seen that proof-of-concept, I'm wondering if we shouldn't make > an effort to support contrib/uuid-ossp with a choice of UUID libraries > underneath it. There is a non-OSSP set of UUID library functions > available on Linux ("libuuid" from util-linux-ng). I don't know whether > that's at all compatible with the BSD functions, but even if it's not, > presumably a shim for it wouldn't be much larger than the BSD patch. Well, if you want to do the work, I'm fine with that. But if you want to just shoot uuid-ossp in the head, I'm fine with that, too. As Peter says, perfectly reasonable alternatives are available. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, May 18, 2014 at 12:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So, having seen that proof-of-concept, I'm wondering if we shouldn't make
>> an effort to support contrib/uuid-ossp with a choice of UUID libraries
>> underneath it. There is a non-OSSP set of UUID library functions
>> available on Linux ("libuuid" from util-linux-ng). I don't know whether
>> that's at all compatible with the BSD functions, but even if it's not,
>> presumably a shim for it wouldn't be much larger than the BSD patch.
> Well, if you want to do the work, I'm fine with that. But if you want
> to just shoot uuid-ossp in the head, I'm fine with that, too. As
> Peter says, perfectly reasonable alternatives are available.
Well, *I* don't want to do that work. I was hoping to find a volunteer,
but the silence has been notable. I think deprecation is the next step.
regards, tom lane
On 22/05/2014 17:07, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, May 18, 2014 at 12:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> So, having seen that proof-of-concept, I'm wondering if we shouldn't make
>>> an effort to support contrib/uuid-ossp with a choice of UUID libraries
>>> underneath it. There is a non-OSSP set of UUID library functions
>>> available on Linux ("libuuid" from util-linux-ng). I don't know whether
>>> that's at all compatible with the BSD functions, but even if it's not,
>>> presumably a shim for it wouldn't be much larger than the BSD patch.
>
>> Well, if you want to do the work, I'm fine with that. But if you want
>> to just shoot uuid-ossp in the head, I'm fine with that, too. As
>> Peter says, perfectly reasonable alternatives are available.
>
> Well, *I* don't want to do that work. I was hoping to find a volunteer,
> but the silence has been notable. I think deprecation is the next step.
This sounds an easy enough task to try and submit a patch, if I'm able
to allocate enough time to work on it.
I have successfully compiled the extension on a NetBSD box using a
slightly modified version of Palle's patch. I have a few doubts though:
- should we keep the extension name? If not, what would be the plan?
- the patch also uses BSD's own md5 and sha1 implementations: for md5 I
should be able to use pg's own core version, but I'm not sure about
sha1, as it lives in pgcrypto. Any suggestion?
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
On Thu, May 22, 2014 at 11:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, May 18, 2014 at 12:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> So, having seen that proof-of-concept, I'm wondering if we shouldn't make
>>> an effort to support contrib/uuid-ossp with a choice of UUID libraries
>>> underneath it. There is a non-OSSP set of UUID library functions
>>> available on Linux ("libuuid" from util-linux-ng). I don't know whether
>>> that's at all compatible with the BSD functions, but even if it's not,
>>> presumably a shim for it wouldn't be much larger than the BSD patch.
>
>> Well, if you want to do the work, I'm fine with that. But if you want
>> to just shoot uuid-ossp in the head, I'm fine with that, too. As
>> Peter says, perfectly reasonable alternatives are available.
>
> Well, *I* don't want to do that work. I was hoping to find a volunteer,
> but the silence has been notable. I think deprecation is the next step.
If we can't get it fixed up, I think we should remove it outright. If
we merely deprecate it, then either people will still be trying to
build and package it (in which case we haven't solved any problem), or
we'll never get around to really removing it, or both.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 22/05/2014 21:55, Matteo Beccati wrote: > On 22/05/2014 17:07, Tom Lane wrote: >> Well, *I* don't want to do that work. I was hoping to find a volunteer, >> but the silence has been notable. I think deprecation is the next step. > > This sounds an easy enough task to try and submit a patch, if I'm able > to allocate enough time to work on it. > > I have successfully compiled the extension on a NetBSD box using a > slightly modified version of Palle's patch. I have a few doubts though: > > - should we keep the extension name? If not, what would be the plan? > - the patch also uses BSD's own md5 and sha1 implementations: for md5 I > should be able to use pg's own core version, but I'm not sure about > sha1, as it lives in pgcrypto. Any suggestion? Maybe I've put the cart before the horse a little bit ;) Anyway, BSD and Linux UUID implementations are slightly different, but I was able to get two variants of the extension to compile on NetBSD and Ubuntu. I don't have the necessary autoconf-fu to "merge" them together though, and to make sure that they compile on the various bsd/linux flavours. You can find the code here: https://github.com/mbeccati/uuid # NetBSD variant https://github.com/mbeccati/uuid/tree/linux # Ubuntu variant For now, I've forked just RhodiumToad's uuid-freebsd extension, but I've made sure make works fine when cloned in the contrib folder. * Both the variants use a copy of pgcrypto md5/sha1 implementations to generate v3 and v5 UUIDs as porting is much easier than trying to use the system provided ones, if any. * I've fixed a bug in v3/v5 generation wrt endianness as the results I was getting didn't match the RFC. * The code is PoC quality and I haven't touched the docs/readme yet. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/
On 23/05/2014 10:05, Matteo Beccati wrote: > You can find the code here: > https://github.com/mbeccati/uuid # NetBSD variant > https://github.com/mbeccati/uuid/tree/linux # Ubuntu variant > > For now, I've forked just RhodiumToad's uuid-freebsd extension, but I've > made sure make works fine when cloned in the contrib folder. > > * Both the variants use a copy of pgcrypto md5/sha1 implementations to > generate v3 and v5 UUIDs as porting is much easier than trying to use > the system provided ones, if any. > * I've fixed a bug in v3/v5 generation wrt endianness as the results I > was getting didn't match the RFC. > * The code is PoC quality and I haven't touched the docs/readme yet. And here's my last effort w/ autoconf support: https://github.com/mbeccati/postgres/compare/postgres:master...master It's surely far from perfect, but maybe closer to something that can be considered as a replacement for OSSP. Especially I'm not that happy about the #ifdefs cluttering the code and AC_SEARCH_LIB putting libuuid in $LIBS. Any suggestion? Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/