Thread: BUG #8271: Configure warning: sys/ucred.h: present but cannot be compiled

The following bug has been logged on the website:

Bug reference:      8271
Logged by:          Emre Hasegeli
Email address:      emre@hasegeli.com
PostgreSQL version: 9.1.9
Operating system:   OpenBSD 5.3 amd64
Description:

Configure warning on OpenBSD 5.3:


checking sys/ucred.h usability... no
checking sys/ucred.h presence... yes
configure: WARNING: sys/ucred.h: present but cannot be compiled
configure: WARNING: sys/ucred.h:     check for missing prerequisite
headers?
configure: WARNING: sys/ucred.h: see the Autoconf documentation
configure: WARNING: sys/ucred.h:     section "Present But Cannot Be
Compiled"
configure: WARNING: sys/ucred.h: proceeding with the preprocessor's result
configure: WARNING: sys/ucred.h: in the future, the compiler will take
precedence
configure: WARNING:     ## ---------------------------------------- ##
configure: WARNING:     ## Report this to pgsql-bugs@postgresql.org ##
configure: WARNING:     ## ---------------------------------------- ##
checking for sys/ucred.h... yes


It appears on 9.1.9, 9.2.4, 9.3beta2; does not appear on 9.0.13.

On 2013-06-30 10:43:49 +0000, emre@hasegeli.com wrote:
> checking sys/ucred.h usability... no
> checking sys/ucred.h presence... yes
> configure: WARNING: sys/ucred.h: present but cannot be compiled
> configure: WARNING: sys/ucred.h:     check for missing prerequisite
> headers?
> configure: WARNING: sys/ucred.h: see the Autoconf documentation
> configure: WARNING: sys/ucred.h:     section "Present But Cannot Be
> Compiled"
> configure: WARNING: sys/ucred.h: proceeding with the preprocessor's result
> configure: WARNING: sys/ucred.h: in the future, the compiler will take
> precedence
> configure: WARNING:     ## ---------------------------------------- ##
> configure: WARNING:     ## Report this to pgsql-bugs@postgresql.org ##
> configure: WARNING:     ## ---------------------------------------- ##
> checking for sys/ucred.h... yes

Could you attach config.log?

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On 2013-06-30 15:11:24 +0300, Emre Hasegeli wrote:
> 2013/6/30 Andres Freund <andres@2ndquadrant.com>:
> > On 2013-06-30 10:43:49 +0000, emre@hasegeli.com wrote:
> > Could you attach config.log?
>
> Attached.

This seems to be caused by be4585b1c27ac5dbdd0d61740d18f7ad9a00e268. The
fault imo lies with openbsd which doesn't include the prerequisite
sys/param.h header which defines NGROUPS:
http://fxr.watson.org/fxr/source/sys/ucred.h?v=OPENBSD
The other BSD flavors seems to get that right.

Before that commit the checks for cmsgcred which includes sys/ucred.h
happened to include params.h... Patch attached, missing the configure
update since I don't have a compatible autoconf on my laptop, to produce
a minimal diff.

It's a bit sad that we didn't notice this despite having spoonbill
reporting it, presumably for a good while:
http://pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=spoonbill&dt=2013-06-29%2011%3A00%3A04&stg=configure

The reason we presumably missed it is that getpeereid is properly
present.

Andrew: Could we perhaps check for the "Report this to" bit in the
buildfarm?

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On 2013-06-30 15:17:20 +0200, Andres Freund wrote:
> Andrew: Could we perhaps check for the "Report this to" bit in the
> buildfarm?

FWIW: I checked that there are no other reports on HEAD atm.

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On 06/30/2013 09:20 AM, Andres Freund wrote:
> On 2013-06-30 15:17:20 +0200, Andres Freund wrote:
>> Andrew: Could we perhaps check for the "Report this to" bit in the
>> buildfarm?
> FWIW: I checked that there are no other reports on HEAD atm.
>


I'm not sure what you're asking here. Where exactly do you thing
buildfarm failures should be reported? There are four mailing lists that
get buildfarm status reports:

  * <http://lists.pgfoundry.org/mailman/listinfo/pgbuildfarm-status-all>
    gets a summary of every single reported build
  * <http://lists.pgfoundry.org/mailman/listinfo/pgbuildfarm-status-fail> gets
    a summary of every build that fails
  * <http://lists.pgfoundry.org/mailman/listinfo/pgbuildfarm-status-chngs>
    gets a summary of every build that results in a status change
  * <http://lists.pgfoundry.org/mailman/listinfo/pgbuildfarm-status-green>
    gets a summary of every build that results in a status change to or
    from green (a.k.a. OK)

These are available in digest form.

What we could possibly add is a feature to email a committer about a
commit included in the changeset of a failing build. The main trick
would be to avoid flooding the committers, so that a commit would only
be notified once. Magnus has suggested something like this previously,
but I haven't looked at it much - I can again. It might not be too hard.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
>> On 2013-06-30 15:17:20 +0200, Andres Freund wrote:
>>> Andrew: Could we perhaps check for the "Report this to" bit in the
>>> buildfarm?

> I'm not sure what you're asking here.

I think he's wishing that if configure prints something like

configure: WARNING: sys/ucred.h: present but cannot be compiled
configure: WARNING: sys/ucred.h:     check for missing prerequisite headers?
configure: WARNING: sys/ucred.h: see the Autoconf documentation
configure: WARNING: sys/ucred.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/ucred.h: proceeding with the preprocessor's result
configure: WARNING: sys/ucred.h: in the future, the compiler will take precedence
configure: WARNING:     ## ---------------------------------------- ##
configure: WARNING:     ## Report this to pgsql-bugs@postgresql.org ##
configure: WARNING:     ## ---------------------------------------- ##

that that ought to be treated as a failure not a success.  I'm not
entirely sure that I agree, but it's an arguable position.

            regards, tom lane

On 06/30/2013 09:49 AM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>>> On 2013-06-30 15:17:20 +0200, Andres Freund wrote:
>>>> Andrew: Could we perhaps check for the "Report this to" bit in the
>>>> buildfarm?
>> I'm not sure what you're asking here.
> I think he's wishing that if configure prints something like
>
> configure: WARNING: sys/ucred.h: present but cannot be compiled
> configure: WARNING: sys/ucred.h:     check for missing prerequisite headers?
> configure: WARNING: sys/ucred.h: see the Autoconf documentation
> configure: WARNING: sys/ucred.h:     section "Present But Cannot Be Compiled"
> configure: WARNING: sys/ucred.h: proceeding with the preprocessor's result
> configure: WARNING: sys/ucred.h: in the future, the compiler will take precedence
> configure: WARNING:     ## ---------------------------------------- ##
> configure: WARNING:     ## Report this to pgsql-bugs@postgresql.org ##
> configure: WARNING:     ## ---------------------------------------- ##
>
> that that ought to be treated as a failure not a success.  I'm not
> entirely sure that I agree, but it's an arguable position.


Oh. Well, if that's a failure then it's up to configure to treat it as
one. The buildfarm doesn't second-guess the exit status of the various
steps, and it doesn't report warnings - if it did we'd be flooded.

cheers

andrew

On 2013-06-30 10:17:50 -0400, Andrew Dunstan wrote:
>
> On 06/30/2013 09:49 AM, Tom Lane wrote:
> >Andrew Dunstan <andrew@dunslane.net> writes:
> >>>On 2013-06-30 15:17:20 +0200, Andres Freund wrote:
> >>>>Andrew: Could we perhaps check for the "Report this to" bit in the
> >>>>buildfarm?
> >>I'm not sure what you're asking here.
> >I think he's wishing that if configure prints something like
> >
> >configure: WARNING: sys/ucred.h: present but cannot be compiled
> >configure: WARNING: sys/ucred.h:     check for missing prerequisite headers?
> >configure: WARNING: sys/ucred.h: see the Autoconf documentation
> >configure: WARNING: sys/ucred.h:     section "Present But Cannot Be Compiled"
> >configure: WARNING: sys/ucred.h: proceeding with the preprocessor's result
> >configure: WARNING: sys/ucred.h: in the future, the compiler will take precedence
> >configure: WARNING:     ## ---------------------------------------- ##
> >configure: WARNING:     ## Report this to pgsql-bugs@postgresql.org ##
> >configure: WARNING:     ## ---------------------------------------- ##
> >
> >that that ought to be treated as a failure not a success.  I'm not
> >entirely sure that I agree, but it's an arguable position.

Exactly. That we presumably had this warning showing up for more than 2
years seems to indicate we should think about doing something different.

> Oh. Well, if that's a failure then it's up to configure to treat it as one.
> The buildfarm doesn't second-guess the exit status of the various steps, and
> it doesn't report warnings - if it did we'd be flooded.

I guess we don't want to do that because it would probably hurt people
building in unusual environments where some variants of this very well
can show up without stopping pg from being built. Many people on such
problems will have no difficulties fixing a minor compilation error, but
fixing configure.in + installing the correct autoconf version is a
higher barrier.
We could add a --strict-mode or so to configure, but afair the handling
of that warning is burried in autoconf itself making this harder. So
I thought adding some grep like thing to the buildfarm might be the
easiest solution.

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On 06/30/2013 11:07 AM, Andres Freund wrote:
> On 2013-06-30 10:17:50 -0400, Andrew Dunstan wrote:
>> On 06/30/2013 09:49 AM, Tom Lane wrote:
>>> Andrew Dunstan <andrew@dunslane.net> writes:
>>>>> On 2013-06-30 15:17:20 +0200, Andres Freund wrote:
>>>>>> Andrew: Could we perhaps check for the "Report this to" bit in the
>>>>>> buildfarm?
>>>> I'm not sure what you're asking here.
>>> I think he's wishing that if configure prints something like
>>>
>>> configure: WARNING: sys/ucred.h: present but cannot be compiled
>>> configure: WARNING: sys/ucred.h:     check for missing prerequisite headers?
>>> configure: WARNING: sys/ucred.h: see the Autoconf documentation
>>> configure: WARNING: sys/ucred.h:     section "Present But Cannot Be Compiled"
>>> configure: WARNING: sys/ucred.h: proceeding with the preprocessor's result
>>> configure: WARNING: sys/ucred.h: in the future, the compiler will take precedence
>>> configure: WARNING:     ## ---------------------------------------- ##
>>> configure: WARNING:     ## Report this to pgsql-bugs@postgresql.org ##
>>> configure: WARNING:     ## ---------------------------------------- ##
>>>
>>> that that ought to be treated as a failure not a success.  I'm not
>>> entirely sure that I agree, but it's an arguable position.
> Exactly. That we presumably had this warning showing up for more than 2
> years seems to indicate we should think about doing something different.
>
>> Oh. Well, if that's a failure then it's up to configure to treat it as one.
>> The buildfarm doesn't second-guess the exit status of the various steps, and
>> it doesn't report warnings - if it did we'd be flooded.
> I guess we don't want to do that because it would probably hurt people
> building in unusual environments where some variants of this very well
> can show up without stopping pg from being built. Many people on such
> problems will have no difficulties fixing a minor compilation error, but
> fixing configure.in + installing the correct autoconf version is a
> higher barrier.
> We could add a --strict-mode or so to configure, but afair the handling
> of that warning is burried in autoconf itself making this harder. So
> I thought adding some grep like thing to the buildfarm might be the
> easiest solution.
>


But that *would* be second-guessing configure's exit status.

I don't understand the reference to autoconf - nobody building Postgres,
including buildfarm members, needs autoconf installed at all. Only
developers and committers need to, and then only when configure.in is
changed.

cheers

andrew

On 2013-06-30 11:19:50 -0400, Andrew Dunstan wrote:
> >>Oh. Well, if that's a failure then it's up to configure to treat it as one.
> >>The buildfarm doesn't second-guess the exit status of the various steps, and
> >>it doesn't report warnings - if it did we'd be flooded.
> >I guess we don't want to do that because it would probably hurt people
> >building in unusual environments where some variants of this very well
> >can show up without stopping pg from being built. Many people on such
> >problems will have no difficulties fixing a minor compilation error, but
> >fixing configure.in + installing the correct autoconf version is a
> >higher barrier.
> >We could add a --strict-mode or so to configure, but afair the handling
> >of that warning is burried in autoconf itself making this harder. So
> >I thought adding some grep like thing to the buildfarm might be the
> >easiest solution.

> But that *would* be second-guessing configure's exit status.

Yes. I think that's the easiest thing in this case.

> I don't understand the reference to autoconf - nobody building Postgres,
> including buildfarm members, needs autoconf installed at all. Only
> developers and committers need to, and then only when configure.in is
> changed.

If we would treat that warning as an error unconditionally - and I am
not sure how easy that is given the way it's emitted - users
encountering them, which usually will be on less common platforms, will
have to patch configure.in to make things work for them. Which is a high
bar.
Given that many of those warnings will *NOT* completely prohibit them
from building postgres that might be overreaching.

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

2013/6/30 Andres Freund <andres@2ndquadrant.com>:
> On 2013-06-30 10:43:49 +0000, emre@hasegeli.com wrote:
> Could you attach config.log?

Attached.

On 6/30/13 11:26 AM, Andres Freund wrote:
> If we would treat that warning as an error unconditionally - and I am
> not sure how easy that is given the way it's emitted - users
> encountering them, which usually will be on less common platforms, will
> have to patch configure.in to make things work for them. Which is a high
> bar.
> Given that many of those warnings will *NOT* completely prohibit them
> from building postgres that might be overreaching.

We could also look into updating Autoconf.  Newer versions proceed with
the compiler's result.  At that point, you can essentially ignore the
warning.

Peter Eisentraut <peter_e@gmx.net> writes:
> On 6/30/13 11:26 AM, Andres Freund wrote:
>> If we would treat that warning as an error unconditionally - and I am
>> not sure how easy that is given the way it's emitted - users
>> encountering them, which usually will be on less common platforms, will
>> have to patch configure.in to make things work for them. Which is a high
>> bar.

> We could also look into updating Autoconf.  Newer versions proceed with
> the compiler's result.  At that point, you can essentially ignore the
> warning.

AFAICT, the result in this case would be that the script comes to the
wrong conclusion about whether ucred.h is available.  Wouldn't that
result in a build failure, or at least missing features?  IOW, don't
we need to fix this test anyway?

However, if newer autoconf versions make only one test per header file
and not two, then +1 for updating.  Should help a bit with configure's
speed problem.

            regards, tom lane

On 2013-07-01 09:19:23 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > On 6/30/13 11:26 AM, Andres Freund wrote:
> >> If we would treat that warning as an error unconditionally - and I am
> >> not sure how easy that is given the way it's emitted - users
> >> encountering them, which usually will be on less common platforms, will
> >> have to patch configure.in to make things work for them. Which is a high
> >> bar.
>
> > We could also look into updating Autoconf.  Newer versions proceed with
> > the compiler's result.  At that point, you can essentially ignore the
> > warning.

While it has other benefits, changing whether autoconf believes the
precompiler or the compiler doesn't seem to fix the issue of tests that
fail silently (as in, don't abort autoconf) because we missed to include
prerequisite headers.
And it doesn't seem to make it neither easier, nor harder for users to
fix configure.in, so unconditionally throwing an hard error even if we
could manage it would still not a good solution.

> AFAICT, the result in this case would be that the script comes to the
> wrong conclusion about whether ucred.h is available.  Wouldn't that
> result in a build failure, or at least missing features?  IOW, don't
> we need to fix this test anyway?

Yes, we need to. I vote for applying something similar to what I
proposed upthread. If we can get rid of some redundancy by using a newer
autoconf we need to touch far more than this tiny bit...

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On 7/1/13 9:19 AM, Tom Lane wrote:
> AFAICT, the result in this case would be that the script comes to the
> wrong conclusion about whether ucred.h is available.  Wouldn't that
> result in a build failure, or at least missing features?  IOW, don't
> we need to fix this test anyway?

The test needs to be fixed, but with a newer Autoconf version we would
(probably) have been alerted about that by a build failure rather than
someone scanning build logs.

On 07/01/2013 05:35 PM, Peter Eisentraut wrote:
> On 7/1/13 9:19 AM, Tom Lane wrote:
>> AFAICT, the result in this case would be that the script comes to the
>> wrong conclusion about whether ucred.h is available.  Wouldn't that
>> result in a build failure, or at least missing features?  IOW, don't
>> we need to fix this test anyway?
> The test needs to be fixed, but with a newer Autoconf version we would
> (probably) have been alerted about that by a build failure rather than
> someone scanning build logs.

I take it you mean a configure failure would occur with a later Autoconf.

cheers

andrew

Peter Eisentraut <peter_e@gmx.net> writes:
> On 7/1/13 9:19 AM, Tom Lane wrote:
>> AFAICT, the result in this case would be that the script comes to the
>> wrong conclusion about whether ucred.h is available.  Wouldn't that
>> result in a build failure, or at least missing features?  IOW, don't
>> we need to fix this test anyway?

> The test needs to be fixed, but with a newer Autoconf version we would
> (probably) have been alerted about that by a build failure rather than
> someone scanning build logs.

I think probably we'd have just not compiled the dependent code, and
would have found out about it only when somebody complained that peer
auth didn't work on OpenBSD.  Not sure that's really a more attractive
behavior :-(

            regards, tom lane

On Mon, 2013-07-01 at 19:27 -0400, Tom Lane wrote:
> I think probably we'd have just not compiled the dependent code, and
> would have found out about it only when somebody complained that peer
> auth didn't work on OpenBSD.  Not sure that's really a more attractive
> behavior :-(

That might be the case, but that's more a problem of how this particular
feature is implemented, not how the configure test works.

Hi,

On 2013-06-30 15:17:20 +0200, Andres Freund wrote:
> On 2013-06-30 15:11:24 +0300, Emre Hasegeli wrote:
> > 2013/6/30 Andres Freund <andres@2ndquadrant.com>:
> > > On 2013-06-30 10:43:49 +0000, emre@hasegeli.com wrote:
> > > Could you attach config.log?
> >
> > Attached.
>
> This seems to be caused by be4585b1c27ac5dbdd0d61740d18f7ad9a00e268. The
> fault imo lies with openbsd which doesn't include the prerequisite
> sys/param.h header which defines NGROUPS:
> http://fxr.watson.org/fxr/source/sys/ucred.h?v=OPENBSD
> The other BSD flavors seems to get that right.
>
> Before that commit the checks for cmsgcred which includes sys/ucred.h
> happened to include params.h... Patch attached, missing the configure
> update since I don't have a compatible autoconf on my laptop, to produce
> a minimal diff.

Could somebody apply the fix (including regenerating /configure)?

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Andres Freund <andres@2ndquadrant.com> writes:
>> Before that commit the checks for cmsgcred which includes sys/ucred.h
>> happened to include params.h... Patch attached, missing the configure
>> update since I don't have a compatible autoconf on my laptop, to produce
>> a minimal diff.

> Could somebody apply the fix (including regenerating /configure)?

The proposed patch seems a bit overcomplicated --- isn't the real
problem that I changed the ordering of the header probes in
be4585b1c27ac5dbdd0d61740d18f7ad9a00e268?  I think I just alphabetized
them in a fit of neatnik-ism, not realizing that there were order
dependencies on some platforms.

            regards, tom lane

On 2013-07-25 09:48:31 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> >> Before that commit the checks for cmsgcred which includes sys/ucred.h
> >> happened to include params.h... Patch attached, missing the configure
> >> update since I don't have a compatible autoconf on my laptop, to produce
> >> a minimal diff.
>
> > Could somebody apply the fix (including regenerating /configure)?
>
> The proposed patch seems a bit overcomplicated --- isn't the real
> problem that I changed the ordering of the header probes in
> be4585b1c27ac5dbdd0d61740d18f7ad9a00e268?  I think I just alphabetized
> them in a fit of neatnik-ism, not realizing that there were order
> dependencies on some platforms.

Hm. It very well might be too complicated. I am not exactly a autoconf
expert...
The problem is that you can't include sys/ucred.h on some platforms
(e.g. openbsd) without first including sys/params.h because the
resulting file won't compile. Unless I misunderstood what you propose a
different order in that AC_CHECK_HEADERS() shouldn't help getting it
there?
Maybe we could get rid of the two separate tests that now use
HAVE_SYS_PARAM_H - I just tried to followed the surrounding patterns.

FWIW I have confirmation via private emails that the patch works at
least on openbsd...

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-07-25 09:48:31 -0400, Tom Lane wrote:
>> The proposed patch seems a bit overcomplicated --- isn't the real
>> problem that I changed the ordering of the header probes in
>> be4585b1c27ac5dbdd0d61740d18f7ad9a00e268?  I think I just alphabetized
>> them in a fit of neatnik-ism, not realizing that there were order
>> dependencies on some platforms.

> Hm. It very well might be too complicated. I am not exactly a autoconf
> expert...

Ah, I was thinking that AC_CHECK_HEADERS would include the
previously-found headers when checking a particular item, but a bit of
research says that's not so.  So we do indeed need something like this.
Will take care of it.

            regards, tom lane

On 07/25/2013 09:48 AM, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
>>> Before that commit the checks for cmsgcred which includes sys/ucred.h
>>> happened to include params.h... Patch attached, missing the configure
>>> update since I don't have a compatible autoconf on my laptop, to produce
>>> a minimal diff.
>> Could somebody apply the fix (including regenerating /configure)?
> The proposed patch seems a bit overcomplicated --- isn't the real
> problem that I changed the ordering of the header probes in
> be4585b1c27ac5dbdd0d61740d18f7ad9a00e268?  I think I just alphabetized
> them in a fit of neatnik-ism, not realizing that there were order
> dependencies on some platforms.
>
>


It looks to me like you didn't reorder anything, you added a test for
sys/ucred.h.

I haven't seen the proposed patch, though.

cheers

andrew

Andres Freund <andres@2ndquadrant.com> writes:
> The problem is that you can't include sys/ucred.h on some platforms
> (e.g. openbsd) without first including sys/params.h because the
> resulting file won't compile.

BTW, after committing this I re-reviewed the thread and realized that
actually this problem is strictly cosmetic.  The net effect of the
configure bug is is that it (1) doesn't set HAVE_SYS_UCRED_H and
as a consequence (2) doesn't set HAVE_STRUCT_CMSGCRED.  However,
that's only examined in one place in libpq, which says:

 * Note: this is dead code as of Postgres 9.1, because current backends will
 * never send this challenge.  But we must keep it as long as libpq needs to
 * interoperate with pre-9.1 servers.  It is believed to be needed only on
 * Debian/kFreeBSD (ie, FreeBSD kernel with Linux userland, so that the
 * getpeereid() function isn't provided by libc).

So on an OpenBSD build that code wouldn't be used anyway (not even
when talking to a pre-9.1 server, if I'm interpreting the comment
correctly).

            regards, tom lane

On 2013-07-25 11:50:47 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > The problem is that you can't include sys/ucred.h on some platforms
> > (e.g. openbsd) without first including sys/params.h because the
> > resulting file won't compile.
>
> BTW, after committing this I re-reviewed the thread and realized that
> actually this problem is strictly cosmetic.  The net effect of the
> configure bug is is that it (1) doesn't set HAVE_SYS_UCRED_H and
> as a consequence (2) doesn't set HAVE_STRUCT_CMSGCRED.

Yes, I've commented on that upthread. The cosmetics are worth fixing
though, since I've posted in this thread several people mailed me
because they thought this was the cause of actually unrelated
problems... The last mail was what reminded me of the patch today ;)

> So on an OpenBSD build that code wouldn't be used anyway (not even
> when talking to a pre-9.1 server, if I'm interpreting the comment
> correctly).

As far as I understood it, it wouldn't be used as long as you're not
talking to a server on another platform that supports AUTH_REQ_SCM_CREDS
serverside. Which is pretty unlikely, I grant you that ;)

Not that it really matters, but I am slightly doubtful about the
"kfreebsd only" claim. Given the age of that code relative do kfreebsd
there at least had to be some more platforms needing that codepath at
some point.

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-07-25 11:50:47 -0400, Tom Lane wrote:
>> So on an OpenBSD build that code wouldn't be used anyway (not even
>> when talking to a pre-9.1 server, if I'm interpreting the comment
>> correctly).

> As far as I understood it, it wouldn't be used as long as you're not
> talking to a server on another platform that supports AUTH_REQ_SCM_CREDS
> serverside. Which is pretty unlikely, I grant you that ;)

But SCM_CREDS is only relevant to Unix-socket connections, so the server
has to be under the same kernel as the client.

> Not that it really matters, but I am slightly doubtful about the
> "kfreebsd only" claim. Given the age of that code relative do kfreebsd
> there at least had to be some more platforms needing that codepath at
> some point.

Of course.  There's some historical context in the commit message for
be4585b1c27ac5dbdd0d61740d18f7ad9a00e268 --- basically the point is that
kfreebsd was the last live platform on which we'd use credentials
messages.

            regards, tom lane