Postgres Enhancement Request

[Zwettler Markus (OIZ)]

CREATEROLE allows users to create new roles also having the CREATEDB privilege 
(at least in version 9.6).

We want special users to be able to CREATEROLE without being able to CREATEDB 
(eg. when usermanagement is done by the application itself).

Please prevent users with CREATEROLE to create roles having CREATEDB (analogous 
SUPERUSER and REPLICATION).

Thanks

Re: Postgres Enhancement Request

[Thomas Kellerer]

Zwettler Markus (OIZ) schrieb am 20.03.2019 um 11:10:
> CREATEROLE allows users to create new roles also having the CREATEDB 
> privilege (at least in version 9.6).
> 
> We want special users to be able to CREATEROLE without being able to CREATEDB 
> (eg. when usermanagement is done by the application itself).
> 
> Please prevent users with CREATEROLE to create roles having CREATEDB 
> (analogous SUPERUSER and REPLICATION).

I agree that would be a welcome enhancement. 

As a workaround, you can create a function owned by a superuser (or any other 
user with the "createrole" privilege) using "security definer" that provides a 
simple "create user" capability and makes sure that the created user does not 
have the createdb privilege. 

The user/role that should be able to create new roles doesn't need the 
createrole privilege at all then. 
All it needs is the execute privilege on the function.

Thomas

Re: WSL (windows subsystem on linux) users will need to turn fsync off as of 11.2

[Hendrickx Pablo]

Who areb

Get Outlook for Android


From: Thomas Munro 
Sent: Tuesday, February 19, 2019 5:31:26 AM
To: James Sewell
Cc: Andres Freund; Ravi Krishna; pgsql-generallists.postgresql.org
Subject: Re: WSL (windows subsystem on linux) users will need to turn fsync off 
as of 11.2

On Tue, Feb 19, 2019 at 5:16 PM James Sewell  wrote:
>> Here's a starter patch that shows one of the approaches discussed.  It
>> gets WSL users to a better place than they were before, by suppressing
>> further warnings after the first one.
>
> This wasn't quite right, updated to check erro for ENOSYS (not rc)
>
> This compiles and stops the panic on WSL (with a single warning).
>
> I haven't tested if a version compiled on Linux will behave the same way - 
> but based on the error messages in the top post it looks like the behavior is 
> the same.

Great.  Thanks for testing, and for the fix!  Well that all sounds
like good news: it corrects the behaviour from 11.2, and also improves
on the previous behaviour which I'd have accepted as a bug if anyone
had reported it.  So the next problem is that we don't have a
consensus on whether this is the right approach, so I don't feel like
I can commit it yet.  Does any want to make another concrete proposal?

--
Thomas Munro
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fenterprisedb.com&data=02%7C01%7Cpablo.hendrickx%40exitas.be%7Ce13b08e515cd465ca6d808d696233602%7C49c3d703357947bfa8887c913fbdced9%7C0%7C1%7C636861475311562797&sdata=4qLSN4n1kGMWIO6luNlNdvDAqV02UhQ4ArqDa%2FCulsU%3D&reserved=0

Re: subscription broken after upgrade to pg11

[Radoslav Nedyalkov]

On Tue, Mar 19, 2019 at 10:37 PM Adrian Klaver 
wrote:

> On 3/19/19 9:35 AM, Radoslav Nedyalkov wrote:
> > Hi All,
> > We're testing upgrade from postgres 10.6 to postgres 11.2 with
> pg_upgrade.
> > Before stopping pg10 we disabled subscription.
> > After upgrade and launching pg11,  the existing logical replication
> > subscription is there and disabled.
> >
> > stest=# \dRs+
> >   List of subscriptions
> >   Name |  Owner   | Enabled | Publication | Synchronous commit |
> >  Conninfo
> >
> --+--+-+-++-
> >   sub1 | postgres | f   | {pub2}  | off|
> > host=10.2.5.8 dbname=test user=postgres
> > (1 row)
> >
> > However after enabling it,  the target table does not get updates,
> > although the subscription looks okay according to the status below.
> >
> > stest=# alter subscription sub1 enable;
> > ALTER SUBSCRIPTION
> > # no updates here
> >
> > stest=# \dRs+
> >  List of subscriptions
> >   Name |  Owner   | Enabled | Publication | Synchronous commit |
> >  Conninfo
> >
> --+--+-+-++-
> >   sub1 | postgres | t   | {pub2}  | off|
> > host=10.2.5.8 dbname=test user=postgres
> >
> > stest=# select * from pg_subscription;
> >   subdbid | subname | subowner | subenabled |   subconninfo
> >   | subslotname | subsynccommit | subpublications
> >
> -+-+--++-+-+---+-
> > 16402 | sub1|   10 | t  | host=10.2.5.8 dbname=test
> > user=postgres | sub1| off   | {pub2}
> >
> > stest=# select * from pg_stat_subscription;
> >   subid | subname | pid  | relid | received_lsn | last_msg_send_time |
> > last_msg_receipt_time | latest_end_lsn |latest_end_time
> >
> ---+-+--+---+--++---++---
> >   16413 | sub1| 2810 |   | 0/145C3400   ||
> > 2019-03-19 16:23:23.650073+00 | 0/145C3320 | 2019-03-19
> > 16:23:23.446651+00
> >
> > Issuing a refresh
> > stest=# alter subscription sub1 refresh publication with (copy_data =
> > false);
> > ALTER SUBSCRIPTION
> >
> > resumes updates , but with a gap in data. Everything up-to to the
> > refresh statement is missing in the target.
> >
> > What we're doing wrong ?
>
> https://www.postgresql.org/docs/11/sql-altersubscription.html
>
> REFRESH PUBLICATION
>
>  Fetch missing table information from publisher. This will start
> replication of tables that were added to the subscribed-to publications
> since the last invocation of REFRESH PUBLICATION or since CREATE
> SUBSCRIPTION.
>
>  refresh_option specifies additional options for the refresh
> operation. The supported options are:
>
>  copy_data (boolean)
>
>  Specifies whether the existing data in the publications that
> are being subscribed to should be copied once the replication starts.
> The default is true.
>
>
> Try with:
>
> copy_data=true
>
>
>I don't think focus is on REFRESH here. It is existing subscription
that should resume and apply changes without discrepancies in the flow.
   First I tried  simply to re-create subscription by retaining replication
slot on the source. However the slot sent already applied changes.
  Obviously exact LSN was lost somehow during upgrade. (how? should it ?)
  So the solution:

On the target before upgrade - disable subscription and get remote_lsn.

stest=# alter subscription sub1 disable;
ALTER SUBSCRIPTION
stest=# select * from pg_replication_origin_status ;
 local_id | external_id | remote_lsn | local_lsn
--+-++---
1 | pg_16473| *0/146E41E0* | 0/2ABDC48
(1 row)

 Upgrade here.

On the target after upgrade execute:

stest=# alter subscription sub1 set (slot_name = NONE);
ALTER SUBSCRIPTION
stest=# drop subscription sub1 ;
DROP SUBSCRIPTION
stest=# create subscription sub1 CONNECTION 'host=10.2.5.8 dbname=test
user=postgres' PUBLICATION pub2 with (slot_name = sub1, create_slot=false,
enabled=false, copy_data=false);
CREATE SUBSCRIPTION
stest=# select oid,* from pg_subscription;
  oid  | subdbid | subname | subowner | subenabled |
 subconninfo   | subslotname | subsynccommit | subpublications
---+-+-+--++-+-+---+-
 16474 |   16402 | sub1|   10 | f  | host=10.2.5.8
dbname=test user=postgres | sub1| off   | {pub2}
(1 row)
stest=# select pg_replication_origin_advance('pg_16474', '*0/146E41E0*');
stest=# select * f

AW: Postgres Enhancement Request

[Zwettler Markus (OIZ)]

We already did and use this at the moment. Unfortunately.

Some out-of-the-box applications can't use functions for user management.
Some users don't want "special" functions for user management.
...

Markus



-Ursprüngliche Nachricht-
Von: Thomas Kellerer  
Gesendet: Mittwoch, 20. März 2019 11:45
An: pgsql-general@lists.postgresql.org
Betreff: Re: Postgres Enhancement Request

Zwettler Markus (OIZ) schrieb am 20.03.2019 um 11:10:
> CREATEROLE allows users to create new roles also having the CREATEDB 
> privilege (at least in version 9.6).
> 
> We want special users to be able to CREATEROLE without being able to CREATEDB 
> (eg. when usermanagement is done by the application itself).
> 
> Please prevent users with CREATEROLE to create roles having CREATEDB 
> (analogous SUPERUSER and REPLICATION).

I agree that would be a welcome enhancement. 

As a workaround, you can create a function owned by a superuser (or any other 
user with the "createrole" privilege) using "security definer" that provides a 
simple "create user" capability and makes sure that the created user does not 
have the createdb privilege. 

The user/role that should be able to create new roles doesn't need the 
createrole privilege at all then. 
All it needs is the execute privilege on the function.

Thomas

Re: Performance of ByteA: ascii vs binary

[Thomas Güttler]

Am 19.03.19 um 20:37 schrieb Peter J. Holzer:

On 2019-03-18 15:33:17 +0100, Thomas Güttler wrote:

I did some benchmarking and in my setup there was major
performance difference.

I tested a ByteA column.

If I used ascii data the tests took 52 seconds.
If I used random binary data the test took 250 seconds.

binary data is (roughly) five times slower than ascii data?

Is this a know fact, or is there something wrong with my benchmark?

I used Python and psycopg2.


I don't see this here (Debian 9, Python 3,5, psycopg2 2.7.6, PostgreSQL
9.5).

I modified my bench-bytea script (https://github.com/hjp/blob-bench) to
restrict the byte values to printable ASCII (32 .. 126). There was
absolutely no difference, as the attached graph shows.


Strange. I saw a big difference.
What did you test?
I tested inserts.

Regards,
  Thomas Güttler



--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines

Re: Postgres Enhancement Request

[Tom Lane]

Thomas Kellerer  writes:
> Zwettler Markus (OIZ) schrieb am 20.03.2019 um 11:10:
>> Please prevent users with CREATEROLE to create roles having CREATEDB 
>> (analogous SUPERUSER and REPLICATION).

> I agree that would be a welcome enhancement. 

No, it wouldn't.  The point of CREATEROLE is to allow user creation
and deletion to be done by a role that's less than full superuser.
If we changed it like that, then you'd be right back at needing
superuser for very routine role creations.  That's *not* an
improvement, even if it somehow fit better into the OP's desired
security model (which he hasn't explained).

regards, tom lane

Re: Postgres Enhancement Request

[Thomas Kellerer]

Tom Lane schrieb am 20.03.2019 um 14:59:
>>> Please prevent users with CREATEROLE to create roles having CREATEDB 
>>> (analogous SUPERUSER and REPLICATION).
> 
>> I agree that would be a welcome enhancement. 
> 
> No, it wouldn't.  The point of CREATEROLE is to allow user creation
> and deletion to be done by a role that's less than full superuser.
> If we changed it like that, then you'd be right back at needing
> superuser for very routine role creations.  That's *not* an
> improvement, even if it somehow fit better into the OP's desired
> security model (which he hasn't explained).

I didn't take this to be a request to remove the createdb privilege in general, 
but a request to have finer grained control what kind of privileges the role 
with createrole can grant to newly created roles (or what it can do in general).

Maybe if "createrole" was a regular privilege (like "create table"), then 
something like this would be possible:

create role user_admin;
grant create role to user_admin;

Thomas

Re: Postgres Enhancement Request

[Tom Lane]

Thomas Kellerer  writes:
> Tom Lane schrieb am 20.03.2019 um 14:59:
>> No, it wouldn't.  The point of CREATEROLE is to allow user creation
>> and deletion to be done by a role that's less than full superuser.
>> If we changed it like that, then you'd be right back at needing
>> superuser for very routine role creations.  That's *not* an
>> improvement, even if it somehow fit better into the OP's desired
>> security model (which he hasn't explained).

> I didn't take this to be a request to remove the createdb privilege in 
> general, but a request to have finer grained control what kind of privileges 
> the role with createrole can grant to newly created roles (or what it can do 
> in general).

Hmm.  Thinking about it a bit more carefully, it does seem bogus that
a role that has CREATEROLE but not CREATEDB can make a role that has
the latter privilege.  It would be more sensible to have a uniform
rule that "you can't grant a privilege you don't have yourself",
which would mean that the OP's problem could perhaps be solved by
making a role that has CREATEROLE but not CREATEDB.

You could imagine going further and applying the full SQL privilege
model to these things, which would make it possible to have a role
that has CREATEDB (so can make DBs itself) but can't pass that
privilege on to others for lack of grant options on CREATEDB.
But that would be a very much bigger chunk of work, and I'm not sure
I see the payback.

regards, tom lane

Windows Server 2019 support state / plans

[Ephebopus]

Hi all

We are looking to upgrade our hosting environment (hosted locally) from a
Windows Server 2008 R2 and an older version of Postgresql (9.1.4).

Googling "postgresql 'windows server 2019'" yields rather few results and
the Downloads page for Windows installers lists Windows Server 2016 as the
latest Windows platform. (https://www.postgresql.org/download/windows/ )

How is support for this OS at the moment (11.2)? If not listed in the
Downloads page because in an unverified/incomplete state at the moment, how
are, if public, the plans for Windows Server 2019 support?

Thanks for any replies.



--
Sent from: http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html

to_timestamp function

[Gustavsson Mikael]

Hi,

We recently upgraded from PG9.6 to PG11 and I have some questions regarding the 
function to_timestamp.

We have an application that for some reason unknown to me uses timestamps with 
hour = 24.
After upgrade we got som problems with this. The solution is to use cast 
instead of the function but im curious if this is intentional.

Examles:

In PG9.6 this works:

to_timestamp('2019-03-20 24:00','-MM-DD HH24:MI')

but in PG11 we get:

ERROR:  date/time field value out of range.

I assume this have something to do with this row in releasenotes for PG10:

Make 
to_timestamp()
 and to_date() reject out-of-range input fields (Artur Zakirov)

  *   For example, previously to_date('2009-06-40','-MM-DD') was accepted 
and returned 2009-07-10. It will now generate an error.

But.

This works in both PG9.6 and PG11:

'2019-03-20 24:00'::timestamp with time zone

and this generates an error in both PG9.6 and PG11:

'2009-06-40'::timestamp with time zone

So my question is, is it intentional that to_timestamp is stricter than cast to 
timestamp?

kr

Mikael Gustavsson
SMHI / Swedish Meteorological and Hydrological Institute

Re: to_timestamp function

[Tom Lane]

Gustavsson Mikael  writes:
> So my question is, is it intentional that to_timestamp is stricter than cast 
> to timestamp?

Yes.  The point of using that function at all is to be strict about the
input format, so being strict about the field values seems to make
sense along with that.  An independent argument for it is mentioned in
the commit message (d3cd36a13):

Historically, something like to_date('2009-06-40','-MM-DD') would
return '2009-07-10' because there was no prohibition on out-of-range
month or day numbers.  This has been widely panned, and it also turns
out that Oracle throws an error in such cases.  Since these functions
are nominally Oracle-compatibility features, let's change that.

regards, tom lane

AW: Postgres Enhancement Request

[Zwettler Markus (OIZ)]

Yes, that would be totally ok. Like the "with [grant|admin] option" privilege 
model in SQL. It should be done with all these predefined top-level database 
roles like CREATEROLE.

It's doesn't only seem bogus but also a security hole when users can get 
privileges they have never been granted.

Markus




-Ursprüngliche Nachricht-
Von: Tom Lane  
Gesendet: Mittwoch, 20. März 2019 15:30
An: Thomas Kellerer 
Cc: pgsql-general@lists.postgresql.org
Betreff: Re: Postgres Enhancement Request

Thomas Kellerer  writes:
> Tom Lane schrieb am 20.03.2019 um 14:59:
>> No, it wouldn't.  The point of CREATEROLE is to allow user creation 
>> and deletion to be done by a role that's less than full superuser.
>> If we changed it like that, then you'd be right back at needing 
>> superuser for very routine role creations.  That's *not* an 
>> improvement, even if it somehow fit better into the OP's desired 
>> security model (which he hasn't explained).

> I didn't take this to be a request to remove the createdb privilege in 
> general, but a request to have finer grained control what kind of privileges 
> the role with createrole can grant to newly created roles (or what it can do 
> in general).

Hmm.  Thinking about it a bit more carefully, it does seem bogus that a role 
that has CREATEROLE but not CREATEDB can make a role that has the latter 
privilege.  It would be more sensible to have a uniform rule that "you can't 
grant a privilege you don't have yourself", which would mean that the OP's 
problem could perhaps be solved by making a role that has CREATEROLE but not 
CREATEDB.

You could imagine going further and applying the full SQL privilege model to 
these things, which would make it possible to have a role that has CREATEDB (so 
can make DBs itself) but can't pass that privilege on to others for lack of 
grant options on CREATEDB.
But that would be a very much bigger chunk of work, and I'm not sure I see the 
payback.

regards, tom lane

Re: Windows Server 2019 support state / plans

[Adrian Klaver]

On 3/20/19 7:55 AM, Ephebopus wrote:

Hi all

We are looking to upgrade our hosting environment (hosted locally) from a
Windows Server 2008 R2 and an older version of Postgresql (9.1.4).

Googling "postgresql 'windows server 2019'" yields rather few results and
the Downloads page for Windows installers lists Windows Server 2016 as the
latest Windows platform. (https://www.postgresql.org/download/windows/ )

How is support for this OS at the moment (11.2)? If not listed in the
Downloads page because in an unverified/incomplete state at the moment, how
are, if public, the plans for Windows Server 2019 support?

Thanks for any replies.


I would say install it on Windows Server 2019 and run your tests and 
report back. This would help the community out with feedback and if 
successful help others who may be facing the same Windows migration.





--
Adrian Klaver
adrian.kla...@aklaver.com

Re: AW: Postgres Enhancement Request

[Gavin Flower]

Hi Markus,

Please see comment at the bottonm of this email!

On 21/03/2019 05:36, Zwettler Markus (OIZ) wrote:

Yes, that would be totally ok. Like the "with [grant|admin] option" privilege 
model in SQL. It should be done with all these predefined top-level database roles like 
CREATEROLE.

It's doesn't only seem bogus but also a security hole when users can get 
privileges they have never been granted.

Markus



[...]

A way of indicating content has been omitted!

In ancient times, early 1990's  '[ omitted ]' was used, but I started 
the trend of using '[...]'.



Hmm.  Thinking about it a bit more carefully, it does seem bogus that a role that has 
CREATEROLE but not CREATEDB can make a role that has the latter privilege.  It would be 
more sensible to have a uniform rule that "you can't grant a privilege you don't 
have yourself", which would mean that the OP's problem could perhaps be solved by 
making a role that has CREATEROLE but not CREATEDB.

You could imagine going further and applying the full SQL privilege model to 
these things, which would make it possible to have a role that has CREATEDB (so 
can make DBs itself) but can't pass that privilege on to others for lack of 
grant options on CREATEDB.
But that would be a very much bigger chunk of work, and I'm not sure I see the 
payback.

regards, tom lane



In the postgres groups, please bottom post, as that is the convention here.

Bottom posting makes it easier to follow what is happening.

You can also intersperse comments an omit chunks that are no longer 
relevant.



Thanks,
Gavin

LDAP on AIX build farm animals

[Thomas Munro]

Hello,

On several AIX BF animals such as tern, I see evidence that it might
be using IBM LDAP:

checking for ldap_initialize... no

And yet the configure options apparently intended to use OpenLDAP:

configure: using CPPFLAGS=
-I/home/nm/sw/nopath/libxml2-32/include/libxml2
-I/home/nm/sw/nopath/uuid-32/include
-I/home/nm/sw/nopath/openldap-32/include
-I/home/nm/sw/nopath/icu58.2-32/include
-I/home/nm/sw/nopath/libxml2-32/include
configure: using LDFLAGS= -L/home/nm/sw/nopath/libxml2-32/lib
-L/home/nm/sw/nopath/uuid-32/lib -L/home/nm/sw/nopath/openldap-32/lib
-L/home/nm/sw/nopath/icu58.2-32/lib
-L/home/nm/sw/nopath/libxml2-32/lib

Another explanation is that it is actually using OpenLDAP, but it's a
version so ancient that it doesn't have OpenLDAP's non-standard
ldap_initialize() function (that'd put it in the 20th century,
pre-2.0).

Personally I think it's valuable to have the IBM LDAP client library
tested in the build farm, since we already have the OpenLDAP,
Microsoft and Apple libraries covered.  I wonder if that is the
complete set of surviving libldap implementations.

Would it be useful for the buildfarm to dump ldd (or equivalent)
output for the binaries it's running so that we can see which
libraries it finished up linking?

-- 
Thomas Munro
https://enterprisedb.com

Re: LDAP on AIX build farm animals

[Tom Lane]

Thomas Munro  writes:
> On several AIX BF animals such as tern, I see evidence that it might
> be using IBM LDAP:
> checking for ldap_initialize... no

Interesting.

> Would it be useful for the buildfarm to dump ldd (or equivalent)
> output for the binaries it's running so that we can see which
> libraries it finished up linking?

+1 for displaying the LDAP library type/version in some form, but

(a) ldd is pretty platform-specific;
(b) you will likely get something like "/usr/lib64/libldap.so"
which isn't too definite about what we're using.

Is there some other way to fingerprint the LDAP implementation?

regards, tom lane

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

[Thomas Munro]

On Wed, Mar 20, 2019 at 10:51 AM Tom Lane  wrote:
> Thomas Munro  writes:
> > Even though I can't reproduce the problem myself, I'm quite keen to go
> > ahead and push the patch I proposed for v12 anyway, and close this
> > case.  Otherwise this problem could just keep coming back until
> > libldap.so is eventually entirely phased out by all distros.  In 2023
> > I want to be working on quantum parallelism or something, not LDAP bug
> > reports.  Any objections?
>
> Do we have any clear reason to believe this'd actually fix Mike's problem?
> AFAIK the analogy to the old destructor-conflict issue is just a guess,
> and we don't really know exactly what is going wrong.

Right, we don't know.  To learn more about the reported crash I think
we'll need Mike to install debug symbols, attach with gdb and make it
crash, then show us the output of "bt".  More info here:
https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD

It'd be nice to be able to rule it out in any future bug reports with
these symptoms though, and it's roughly in line with what we see the
rest of the open source ecosystem doing about this problem.

> It's reasonable to assume that the proposed patch won't cause real issues
> on any modern platform, but I'm not sure we can assume that for old ones,
> so the whole thing is making me a bit nervous.  Still, it's nice
> simplification to not have different frontend and backend LDAP libs.

Sure, it's possible that some BF animal will fail to link the backend
for some reason that requires a bit of investigation and a follow-up
patch.  Are you thinking of systems not covered by the BF?

Unless the server is being built with an extremely small set of
configure options enabled, it's almost certainly already linking
something that pulls in the platform's threading library (SSL, GSSAPI,
XML2, ...).  If someone out there is not enabling any of that stuff
because their system doesn't like threads, they can use
--disable-thread-safety to avoid the effects of this change.

> As far as the specifics of the patch go, I don't like that you didn't
> adjust any of the comments near pthread_is_threaded_np() usages.

Hmm.  The comments seemed OK to me without adjustment, is there
something specific that bothered you?  The errhint about LC_ALL is
wrong though, it's macOS-specific.  So I think I should change the
hint to "On macOS, ...", or I guess make it conditional.

-- 
Thomas Munro
https://enterprisedb.com

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

[Tom Lane]

Thomas Munro  writes:
> On Wed, Mar 20, 2019 at 10:51 AM Tom Lane  wrote:
>> It's reasonable to assume that the proposed patch won't cause real issues
>> on any modern platform, but I'm not sure we can assume that for old ones,
>> so the whole thing is making me a bit nervous.

> Sure, it's possible that some BF animal will fail to link the backend
> for some reason that requires a bit of investigation and a follow-up
> patch.  Are you thinking of systems not covered by the BF?

No, I'm thinking that a "followup patch" might be impossible.

> Unless the server is being built with an extremely small set of
> configure options enabled, it's almost certainly already linking
> something that pulls in the platform's threading library (SSL, GSSAPI,
> XML2, ...).

Yeah, but if somebody is relying on LDAP and not any of those other
things, they won't be happy.

> If someone out there is not enabling any of that stuff
> because their system doesn't like threads, they can use
> --disable-thread-safety to avoid the effects of this change.

No, that's nonsense; --disable-thread-safety only affects what happens
on the frontend side.

>> As far as the specifics of the patch go, I don't like that you didn't
>> adjust any of the comments near pthread_is_threaded_np() usages.

> Hmm.  The comments seemed OK to me without adjustment, is there
> something specific that bothered you?

The comment at postmaster.c:1339 is very specific about how there's
a problem with macOS's libintl.  On the basis of that, nobody would
expect that there's a need to do anything on any other platform.
I think we should at least add something about how we're worried
about libldap_r maybe causing the backend to become multithreaded.

> The errhint about LC_ALL is
> wrong though, it's macOS-specific.

Yeah, but that's part and parcel with the comment.

regards, tom lane

Re: LDAP on AIX build farm animals

[Noah Misch]

On Thu, Mar 21, 2019 at 12:21:58PM +1300, Thomas Munro wrote:
> On several AIX BF animals such as tern, I see evidence that it might
> be using IBM LDAP:
> 
> checking for ldap_initialize... no

> Another explanation is that it is actually using OpenLDAP, but it's a
> version so ancient that it doesn't have OpenLDAP's non-standard
> ldap_initialize() function (that'd put it in the 20th century,
> pre-2.0).

It's openldap-2.4.45.  The conclusion that ldap_initialize() is absent stems
from a bug in "configure".  This system has LDAP_LIBS_BE='-lldap -llber' due
to EXTRA_LDAP_LIBS=-llber, but the ldap_initialize() test is done without
-llber.  Relevant config.log:

https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=mandrill&dt=2019-03-20%2021%3A47%3A35&stg=config

On Wed, Mar 20, 2019 at 11:35:39PM -0400, Tom Lane wrote:
> Thomas Munro  writes:
> > Would it be useful for the buildfarm to dump ldd (or equivalent)
> > output for the binaries it's running so that we can see which
> > libraries it finished up linking?
> 
> +1 for displaying the LDAP library type/version in some form, but
> 
> (a) ldd is pretty platform-specific;
> (b) you will likely get something like "/usr/lib64/libldap.so"
> which isn't too definite about what we're using.
> 
> Is there some other way to fingerprint the LDAP implementation?

I would use ldap_get_option(LDAP_OPT_API_INFO), which gives you a vendor name
string and a version number, among other information.