Jan Wieck wrote:
> On 6/10/2004 2:11 AM, Tom Lane wrote:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to
> >> be supplied by the connection string in libpq on platforms that want
> >> threads and don't have getpwuid_r()
Jan Wieck wrote:
> > I looked over the code and the only place getpwuid_r (through
> > pqGetpwuid) is used is in libpq to look up the default username based on
> > the euid for the connection to the backend. Unfortunately, I can't find
> > any other way to do such a lookup in a thread-safe manner
On 6/10/2004 8:49 AM, Bruce Momjian wrote:
Jan Wieck wrote:
Make it so that --enable-thread-safety bombs out, but make another
--enable-thread-safey-anyway work the way Tom descibed it.
Sure, we can do that by just not running the thread_test program. In
fact a cross-compile already skips running
Jan Wieck wrote:
> On 6/10/2004 2:11 AM, Tom Lane wrote:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to
> >> be supplied by the connection string in libpq on platforms that want
> >> threads and don't have getpwuid_r()
On 6/10/2004 2:11 AM, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to
be supplied by the connection string in libpq on platforms that want
threads and don't have getpwuid_r() (Solaris, FreeBSD, etc.)?
AFAICS that was
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to
> be supplied by the connection string in libpq on platforms that want
> threads and don't have getpwuid_r() (Solaris, FreeBSD, etc.)?
AFAICS that was not what Jan was suggesting at
Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to
be supplied by the connection string in libpq on platforms that want
threads and don't have getpwuid_r() (Solaris, FreeBSD, etc.)?
If so, I can easily create a patch and apply it.
---
Jan Wieck wrote:
> On 6/9/2004 1:44 PM, Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> On 6/9/2004 1:04 PM, Bruce Momjian wrote:
> >>
> >> > What we really need is a way to do the uid->username mapping in a
> >> > thread-safe way. Could we check the environment for $USER or $LOGNAME?
> >> > Co
On 6/9/2004 1:44 PM, Bruce Momjian wrote:
Jan Wieck wrote:
On 6/9/2004 1:04 PM, Bruce Momjian wrote:
> What we really need is a way to do the uid->username mapping in a
> thread-safe way. Could we check the environment for $USER or $LOGNAME?
> Could we require them to be set for thread builds on O
Jan Wieck wrote:
> On 6/9/2004 1:04 PM, Bruce Momjian wrote:
>
> > What we really need is a way to do the uid->username mapping in a
> > thread-safe way. Could we check the environment for $USER or $LOGNAME?
> > Could we require them to be set for thread builds on OS's without
> > getpwuid_r and
On 6/9/2004 1:04 PM, Bruce Momjian wrote:
What we really need is a way to do the uid->username mapping in a
thread-safe way. Could we check the environment for $USER or $LOGNAME?
Could we require them to be set for thread builds on OS's without
getpwuid_r and in cases where the username is not spe
Well, looks like you are missing getpwuid_r():
Your system uses getpwuid() which is not thread-safe. **
and we don't have any workaround for this.
---
Jan Wieck wrote:
> On 6/9/2004 11:16 AM, Bruce Momjian wrote:
>
Jan Wieck wrote:
> On 6/9/2004 11:45 AM, Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> The problem is that if your thread-safety tests fail, there is no way to
> >> build libpq with -pthread and -DREENTRANT or whatever is required on
> >> that platform. On Solaris this results in errno being
Jan Wieck wrote:
> On 6/9/2004 9:36 AM, Bruce Momjian wrote:
> >
> >> Also, I would suggest that we allow to build the libpq with thread
> >> specific compiler options, even if it is not entirely thread safe. It
> >> would require that a really multithreaded application has to have
> >> mutexes
On 6/9/2004 11:16 AM, Bruce Momjian wrote:
Jan Wieck wrote:
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
> Jan Wieck wrote:
>> I am wondering why thread_test.c is checking for mktemp()? That function
>> is nowhere used in the libpq.
>
> Uh, it isn't checking for mktemp, it is using it, and it is usi
On 6/9/2004 11:45 AM, Bruce Momjian wrote:
Jan Wieck wrote:
The problem is that if your thread-safety tests fail, there is no way to
build libpq with -pthread and -DREENTRANT or whatever is required on
that platform. On Solaris this results in errno being defined as
extern int errno;
as sup
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
Jan Wieck wrote:
I am wondering why thread_test.c is checking for mktemp()? That function
is nowhere used in the libpq.
Uh, it isn't checking for mktemp, it is using it, and it is using it
because someone didn't like hard-coded paths I was using in the pas
Jan Wieck wrote:
> On 6/9/2004 9:36 AM, Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> I am wondering why thread_test.c is checking for mktemp()? That function
> >> is nowhere used in the libpq.
> >
> > Uh, it isn't checking for mktemp, it is using it, and it is using it
> > because someone di
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
Also, I would suggest that we allow to build the libpq with thread
specific compiler options, even if it is not entirely thread safe. It
would require that a really multithreaded application has to have
mutexes around certain operations, but being entir
Jan Wieck wrote:
> I am wondering why thread_test.c is checking for mktemp()? That function
> is nowhere used in the libpq.
Uh, it isn't checking for mktemp, it is using it, and it is using it
because someone didn't like hard-coded paths I was using in the past.
Is there something wrong with usi
I am wondering why thread_test.c is checking for mktemp()? That function
is nowhere used in the libpq.
Also, I would suggest that we allow to build the libpq with thread
specific compiler options, even if it is not entirely thread safe. It
would require that a really multithreaded application h
21 matches
Mail list logo
