Debian readline/libedit breakage

[Dimitri Fontaine-7]

Magnus Hagander <[hidden email]> writes:
> On Sat, Feb 12, 2011 at 22:46, Dimitri Fontaine <[hidden email]> wrote:
>> If we really believe that the debian interpretation of the licence issue
>> here is moot, surely the easiest action is to offer a debian package
>> repository hosted in the postgresql.org infrastructure.
>>
> Are you volunteering? ;)

I would, yes.  I would benefit from that in more than one place, and of
course we would have to ship extensions packages for all supported major
versions too, which is something I've been working on for debian. See

  http://packages.debian.org/squeeze/postgresql-server-dev-all

Now, what I think I would do about the core package is a quite simple
backport of them, using Martin's excellent work.  Do we want our own QA
on them?  If yes, I think I would need some help here, maybe with some
build farm support for running from our debian packages rather than from
either CVS or git.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Charles.McDevitt]

> [hidden email] wrote:
> > The GNU people will never be 100% satisfied by anything you do to psql, other
> than making it GPL.
> > Readline is specifically licensed in a way to try to force this (but many disagree
> with their ability to force this).
> >
>
> The "GNU people" are perfectly content with the license of PostgreSQL.
> They are unhappy with the license terms of OpenSSL, which is fair
> because they are ridiculous.  Eric Young and the rest of the
> contributors produced a useful piece of software, and made it considerly
> less valuable to the world due to the ego trip terms:
> http://www.openssl.org/source/license.html -- the worst specific problem
> is the requirement to acknowledge OpenSSL use in advertising of projects
> that use it.
>
> The PostgreSQL community has had similar issues with popular software
> commonly used on top of PostgreSQL, that happened to use a non-standard
> license with unique terms.  It would be both hypocritical and incorrect
> to now blame the GNU projects for taking a similar stand on this one.

You are correct... I overreacted, after having run into problems in the past with GPL (vs LGPL) issues.
My apologies to all for adding stupid distracting comments to this thread.

It would be wonderful if the OpenSSL people would compromise on this, but I suppose that isn't possible.

I'd love to see libedit get better, and would like to see that solution, because OpenSSL's FIPS compliance really helps with Federal customers, but I realize that involves a lot of effort.
I hope if the PostgreSQL project goes down the path of switching to GnuTLS, OpenSSL remains an option (for the server side).



--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Greg Smith-21]

Dimitri Fontaine wrote:
> Now, what I think I would do about the core package is a quite simple
> backport of them, using Martin's excellent work.  Do we want our own QA
> on them?  If yes, I think I would need some help here, maybe with some
> build farm support for running from our debian packages rather than from
> either CVS or git.
>  

What the RPM packaging does is run this (approximately):

        pushd src/test/regress
        make all
        make MAX_CONNECTIONS=5 check

Something similar might be sufficient for QA on the Debian packaging
too.  The overhead of the buildfarm makes sense if you want to rebuild
after every single commit.  It may be overkill to go through that just
for testing .deb packaging, which realistically you're only going to
want to do after each point release.

--
Greg Smith   2ndQuadrant US    [hidden email]   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us



--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Dimitri Fontaine-7]

Greg Smith <[hidden email]> writes:
> What the RPM packaging does is run this (approximately):

Well building the debian package also run make check.  My question is if
that's enough QA here for us?

The other side of things if that we will need to provide for a debian
repository with support for at least lenny and squeeze and sid, and i386
and amd64.  Maybe some more.  We will need some build environments here.

Anybody thinking we should somehow include ubuntu in the mix?  If yes,
which versions?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Magnus Hagander-2]

On Sun, Feb 13, 2011 at 12:09, Dimitri Fontaine <[hidden email]> wrote:
> Greg Smith <[hidden email]> writes:
>> What the RPM packaging does is run this (approximately):
>
> Well building the debian package also run make check.  My question is if
> that's enough QA here for us?

Don't the RPM building guys (Hi, Devrim!) also run the tests on an
installed version of the RPMs? Should be easy enough to automate
something like that, no? Though there obviously has to be some point
where to stop - should we test both install and upgrade?


> The other side of things if that we will need to provide for a debian
> repository with support for at least lenny and squeeze and sid, and i386
> and amd64.  Maybe some more.  We will need some build environments here.

I think i386 and amd64 are enough, really. We could add more later if
necessary, but i don't think we need to.

I assume this can be easily virtualized - e.g. having one VM for each
version and just boot it up, update all dependencis, build, and shut
down? in fact, shouldn't there be tools around already that do this
automated?



> Anybody thinking we should somehow include ubuntu in the mix?  If yes,
> which versions?

Yes, since according to a comment somewhere the same issue will bubble
into ubuntu soon. At this point, definitely 8.04 and 10.04, and
probably 10.10. If things can be easily automated, it would be great
if we could do *all* supported ubuntu, but doing LTS and the latest
one or two non-LTS releases.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Dimitri Fontaine-7]

Magnus Hagander <[hidden email]> writes:
> I think i386 and amd64 are enough, really. We could add more later if
> necessary, but i don't think we need to.

Ok.

> I assume this can be easily virtualized - e.g. having one VM for each
> version and just boot it up, update all dependencis, build, and shut
> down? in fact, shouldn't there be tools around already that do this
> automated?

Yes, see pbuilder.  You prepare a debootstrap environment (that's a
tar.gz with a bare minimum debian installation in that you can chroot to
to build package) and pbuilder will apt-get build-dep then debuild for
you then copy the resulting debs out of the chroot and remove it.

You can even build i386 packages from an amd64 OS, I'm doing that
nowadays for the emacs-snapshot package for ubuntu.  I'm building from
the debian package someone else is doing.

>> Anybody thinking we should somehow include ubuntu in the mix?  If yes,
>> which versions?
>
> Yes, since according to a comment somewhere the same issue will bubble
> into ubuntu soon. At this point, definitely 8.04 and 10.04, and
> probably 10.10. If things can be easily automated, it would be great
> if we could do *all* supported ubuntu, but doing LTS and the latest
> one or two non-LTS releases.

Well, that needs I guess either several ubuntu VM or pbuilder support
for ubuntu debootstraps, will check about that.

--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Michael Banck]

On Sun, Feb 13, 2011 at 12:56:03PM +0100, Dimitri Fontaine wrote:

> Magnus Hagander <[hidden email]> writes:
> > Yes, since according to a comment somewhere the same issue will
> > bubble
> > into ubuntu soon. At this point, definitely 8.04 and 10.04, and
> > probably 10.10. If things can be easily automated, it would be great
> > if we could do *all* supported ubuntu, but doing LTS and the latest
> > one or two non-LTS releases.
>
> Well, that needs I guess either several ubuntu VM or pbuilder support
> for ubuntu debootstraps, will check about that.

As pbuilder just runs debootstrap on --create and (Debian) debootstrap
supports the Ubuntu releases, this is not an issue.


Michael

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Dimitri Fontaine-7]

Michael Banck <[hidden email]> writes:
> As pbuilder just runs debootstrap on --create and (Debian) debootstrap
> supports the Ubuntu releases, this is not an issue.

Great.  It seems that a single amd64 build VM would allow us to build
all those binary packages for i386 and amd64, for several debian and
ubuntu releases.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Markus Wanner]

Dimitri,

On 02/12/2011 11:18 PM, Dimitri Fontaine wrote:
> Magnus Hagander <[hidden email]> writes:
>> Are you volunteering? ;)

Once upon a time, I started such an approach, see packages.bluegap.ch.
However, I didn't upgrade these packages for quite some time, because I
didn't need them anymore for my day job.  I received at least two mails
thanking me for this service.  (And judging from the server logs, I'm
afraid they still use that unmaintained repository).

> Now, what I think I would do about the core package is a quite simple
> backport of them, using Martin's excellent work.

Yeah, I've mostly run into Debian specific compatibility issues (like
newer debhelper versions and stuff like that).

Another major annoyance might be that (IIRC) postgresql-common has the
knowledge about which Postgres versions are supported.  So you don't
ever want the Debian package to override the one you are providing.
However, that means you either need to always be ahead of the Debian
repo (version wise) or you need to rename that package (to something
that's easier to your ears, like postgres-common *ducks*)

> Do we want our own QA
> on them?  If yes, I think I would need some help here, maybe with some
> build farm support for running from our debian packages rather than from
> either CVS or git.

I once had an issue with an upgrade.  Testing that sucks big time,
because the number of combinations grows exponentially, and I didn't see
any good way to automate that kind of testing.

But yeah, as long as Debian itself doesn't provide at least the newest
few major versions still supported upstream, it would certainly make
sense for the Postgres project to provide its own Debian / Ubuntu
repositories.

Regards

Markus Wanner

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Dimitri Fontaine-7]

Markus Wanner <[hidden email]> writes:
> Once upon a time, I started such an approach, see packages.bluegap.ch.
> However, I didn't upgrade these packages for quite some time, because I
> didn't need them anymore for my day job.  I received at least two mails
> thanking me for this service.  (And judging from the server logs, I'm
> afraid they still use that unmaintained repository).

Hey, wanna join the fun?  That'd be awesome :)

>> Now, what I think I would do about the core package is a quite simple
>> backport of them, using Martin's excellent work.
>
> Yeah, I've mostly run into Debian specific compatibility issues (like
> newer debhelper versions and stuff like that).
>
> Another major annoyance might be that (IIRC) postgresql-common has the
> knowledge about which Postgres versions are supported.  So you don't
> ever want the Debian package to override the one you are providing.
> However, that means you either need to always be ahead of the Debian
> repo (version wise) or you need to rename that package (to something
> that's easier to your ears, like postgres-common *ducks*)

Well in fact if you install a PostgreSQL version that is not officially
supported in the debian release you're working with, then the script
/usr/share/postgresql-common/supported-versions will output it too.

> But yeah, as long as Debian itself doesn't provide at least the newest
> few major versions still supported upstream, it would certainly make
> sense for the Postgres project to provide its own Debian / Ubuntu
> repositories.

+1  That's a big service to offer to our users.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Markus Wanner]

On 02/14/2011 10:23 AM, Dimitri Fontaine wrote:
> Hey, wanna join the fun?  That'd be awesome :)

Sure, I'll try to help.  Don't be surprised if that's not too often,
though.  I currently cannot promise to provide packaging in any kind of
timely fashion.  :-(

> Well in fact if you install a PostgreSQL version that is not officially
> supported in the debian release you're working with, then the script
> /usr/share/postgresql-common/supported-versions will output it too.

That's pretty much what I meant.  I tried to avoid that warning by
providing a newer version of the postgresql-common package.  However,
that approach doesn't work well with upgrades from Debian (because then
you get the warning back).

Another thing I tried was adding support for release candidates.  The
ability to distribute these as Debian packages could help getting them
more tested.  However, the "rc" in the version identifier isn't
currently appreciated by the perl scripts provided.  Anyway, that's
probably not top priority.

Where do we start?  How would you like to organize this?

(Martin used to have a git branch per distribution and per major
version.  That quickly gives you lots of branches and lots of only
slightly different code bases to work on.  Patching (or cherry picking)
back and forth turned out to be quite a mess.  Ideally I'd envision some
kind of template system to build all of the variations.  That would make
the minor differences obvious).

Markus


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Cédric Villemain-3]

2011/2/14 Markus Wanner <[hidden email]>:

> On 02/14/2011 10:23 AM, Dimitri Fontaine wrote:
>> Hey, wanna join the fun?  That'd be awesome :)
>
> Sure, I'll try to help.  Don't be surprised if that's not too often,
> though.  I currently cannot promise to provide packaging in any kind of
> timely fashion.  :-(
>
>> Well in fact if you install a PostgreSQL version that is not officially
>> supported in the debian release you're working with, then the script
>> /usr/share/postgresql-common/supported-versions will output it too.
>
> That's pretty much what I meant.  I tried to avoid that warning by
> providing a newer version of the postgresql-common package.  However,
> that approach doesn't work well with upgrades from Debian (because then
> you get the warning back).

one way might be to suggest apt-preferences here, I believe.

>
> Another thing I tried was adding support for release candidates.  The
> ability to distribute these as Debian packages could help getting them
> more tested.  However, the "rc" in the version identifier isn't
> currently appreciated by the perl scripts provided.  Anyway, that's
> probably not top priority.
>
> Where do we start?  How would you like to organize this?

First, we must have an agreement here.

Is debian.postgresql.org to host and distribute the debian packages
(and the ubuntu's) linked with readline and openSSL something that we
want and assume ?

So far, it looks like. Before pushing more efforts here, I would like
people who not agree to stand up. Other options exists like a 3rd
party website, but this is not my favorite solution.

>
> (Martin used to have a git branch per distribution and per major
> version.  That quickly gives you lots of branches and lots of only
> slightly different code bases to work on.  Patching (or cherry picking)
> back and forth turned out to be quite a mess.  Ideally I'd envision some
> kind of template system to build all of the variations.  That would make
> the minor differences obvious).

--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Markus Wanner]

Cédric,

thanks for taking a step back and bringing in the bigger picture.

On 02/14/2011 11:57 AM, Cédric Villemain wrote:
> one way might be to suggest apt-preferences here, I believe.

Agreed, might be the cleanest way from a technical POV.

> Is debian.postgresql.org to host and distribute the debian packages
> (and the ubuntu's) linked with readline and openSSL something that we
> want and assume ?

Magnus confirmed on IRC, that they'd be willing to host such a repository.

> So far, it looks like. Before pushing more efforts here, I would like
> people who not agree to stand up. Other options exists like a 3rd
> party website, but this is not my favorite solution.

Well, I consider providing packages for more major versions in parallel
a good service anyway.  (So this probably deserves its own thread).

But yes, to solve the OPs issue with such a custom repository, we'd need
to be prepared to be responsible for providing a Postgres binary that
links to readline and OpenSSL at the same time.  Are we?

Regards

Markus Wanner

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Markus Wanner]

Hi,

On 02/10/2011 11:34 PM, Joshua D. Drake wrote:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109
>
> It seems we may have a problem to consider. As far as I know, we are the
> only major platform that supports libedit but our default is readline.
> Unfortunately readline is not compatible with OpenSSL (apparently?)
> licensing.

Anybody realized that this Debian bug (and several others) got closed in
the mean time (Sunday)?  According to the changelog [1], Martin Pitt
(which I'm CC'ing here, as he might not be aware of this thread, yet)
worked around this issue by pre-loading readline via LD_PRELOAD for psql.

Personally, I'm a bit suspicious about that solution (technically as
well as from a licensing perspective), but it's probably the simplest
way to let only psql link against readline.

Regards

Markus Wanner


[1]: Changelog for postgresql-common on Debian:
http://packages.debian.org/changelogs/pool/main/p/postgresql-common/current/changelog

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Magnus Hagander-2]

On Mon, Feb 14, 2011 at 13:37, Markus Wanner <[hidden email]> wrote:

> Hi,
>
> On 02/10/2011 11:34 PM, Joshua D. Drake wrote:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109
>>
>> It seems we may have a problem to consider. As far as I know, we are the
>> only major platform that supports libedit but our default is readline.
>> Unfortunately readline is not compatible with OpenSSL (apparently?)
>> licensing.
>
> Anybody realized that this Debian bug (and several others) got closed in
> the mean time (Sunday)?  According to the changelog [1], Martin Pitt
> (which I'm CC'ing here, as he might not be aware of this thread, yet)
> worked around this issue by pre-loading readline via LD_PRELOAD for psql.
>
> Personally, I'm a bit suspicious about that solution (technically as
> well as from a licensing perspective), but it's probably the simplest
> way to let only psql link against readline.

That is a rather ugly workaround, but if it works and actually fixes
the license considerations, then it's at least better than nothing at
all.

Not sure it's a reason not to have our own packaging (mainly because
we could provide the version compatibility mix), but it would
certainly reduce the urgency.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Cédric Villemain-3]

2011/2/14 Magnus Hagander <[hidden email]>:

> On Mon, Feb 14, 2011 at 13:37, Markus Wanner <[hidden email]> wrote:
>> Hi,
>>
>> On 02/10/2011 11:34 PM, Joshua D. Drake wrote:
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109
>>>
>>> It seems we may have a problem to consider. As far as I know, we are the
>>> only major platform that supports libedit but our default is readline.
>>> Unfortunately readline is not compatible with OpenSSL (apparently?)
>>> licensing.
>>
>> Anybody realized that this Debian bug (and several others) got closed in
>> the mean time (Sunday)?  According to the changelog [1], Martin Pitt
>> (which I'm CC'ing here, as he might not be aware of this thread, yet)
>> worked around this issue by pre-loading readline via LD_PRELOAD for psql.
>>
>> Personally, I'm a bit suspicious about that solution (technically as
>> well as from a licensing perspective), but it's probably the simplest
>> way to let only psql link against readline.
>
> That is a rather ugly workaround, but if it works and actually fixes
> the license considerations, then it's at least better than nothing at
> all.

Yes!

>
> Not sure it's a reason not to have our own packaging (mainly because
> we could provide the version compatibility mix), but it would
> certainly reduce the urgency.

I agree.
"Consider providing debian packages at debian.postgresql.org"
Do we push that on the TODO list  ?

I believe it can come promptly after the extension stuff is done :)

--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Devrim GÜNDÜZ]

On Mon, 2011-02-14 at 13:52 +0100, Cédric Villemain wrote:
> "Consider providing debian packages at debian.postgresql.org"

apt.postgresql.org, please. :)
--
Devrim GÜNDÜZ
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

[Cédric Villemain-3]

2011/2/14 Devrim GÜNDÜZ <[hidden email]>:
> On Mon, 2011-02-14 at 13:52 +0100, Cédric Villemain wrote:
>> "Consider providing debian packages at debian.postgresql.org"
>
> apt.postgresql.org, please. :)

sure !!!

--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Martin Pitt-3]

Hello all,

thanks Markus for CC'ing me, I'm not on -hackers@.

Markus Wanner [2011-02-14 13:37 +0100]:
> On 02/10/2011 11:34 PM, Joshua D. Drake wrote:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109

Note that the recent discussions happened on bug 608442, in particular

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608442#30

and the following comments.

> Personally, I'm a bit suspicious about that solution (technically as
> well as from a licensing perspective), [...]

For the record, so am I (see comment 30 in the link above), as it uses
the very same ld.so in both cases. However, Andreas Barth pointed out
that with LD_PRELOAD it's guaranteed that we do not "import" any code
from the libreadline header files, which guarantees that psql doesn't
become something that can be considered a "derived work".

Technically, this is a bit fragile, of course, as there might be some
subtle ABI differences which lead to crashes. However, the preloading
workaround already makes the situation so much better than before, so
IMHO it's better than the previous status quo.

I don't really like this situation, and personally I'd rather move
back to libreadline until OpenSSL or readline or PostgreSQL threatens
Debian with a legal case for license violation (I daresay that the
chances of this happening are very close to zero..). But oh well..

Thanks, and sorry for all the madness this created!

Martin

--
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

[Markus Wanner]

Martin,

On 02/14/2011 02:08 PM, Martin Pitt wrote:
> thanks Markus for CC'ing me, I'm not on -hackers@.

Sure.

> Note that the recent discussions happened on bug 608442, in particular
>
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608442#30

Thanks for this pointer.

> Markus Wanner [2011-02-14 13:37 +0100]:
>> Personally, I'm a bit suspicious about that solution (technically as
>> well as from a licensing perspective), [...]
>
> For the record, so am I (see comment 30 in the link above)

That's good to hear.  ;-)

> as it uses
> the very same ld.so in both cases. However, Andreas Barth pointed out
> that with LD_PRELOAD it's guaranteed that we do not "import" any code
> from the libreadline header files, which guarantees that psql doesn't
> become something that can be considered a "derived work".

Hm.. interesting reasoning. But yes, there is something to it.  It's not
really the linking that matters, it seems.

> Technically, this is a bit fragile, of course, as there might be some
> subtle ABI differences which lead to crashes. However, the preloading
> workaround already makes the situation so much better than before, so
> IMHO it's better than the previous status quo.

Absolutely, thanks for taking care.

Regards

Markus Wanner

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers