Re: [PATCHES] listening addresses

2004-03-21 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes:
 Submitted for review.

Okay, some random comments:

 ! char   *ListenAddresses = localhost;

I think you made this mistake in the log_line_prefix patch too.  The
contents of a GUC string var should always be either NULL or a pointer
to a malloc'd string --- ergo, its initial state must be NULL.  It's
pure luck that GUC doesn't dump core trying to free() this pointer.

 + /* 
 +  * check if ListenAddresses is empty or all spaces
 +  */

Why do you need this test (or the NetServer bool) at all?  Just scan
the string and bind to whatever it mentions.

BTW it'd be better to use isspace() instead of a hardwired test for ' '.

 ! if (strcmp(ListenAddresses,*) != 0)

This seems a bit nonrobust since it will fail if any whitespace is
added.  I think it'd be better to test whether any individual hostname
extracted from the string is '*'.

 + if (ListenSocket[0] == -1)
 + ereport(FATAL,
 + (errmsg(not listening on any socket)));

Good but I don't like the wording of the error very much.  Maybe could
not bind to any socket?  Doesn't seem quite right either.  [thinks...]
There are really two cases here:
* listen_addresses is empty and the machine doesn't have Unix
  sockets
* listen_addresses contains (only) bogus addresses, and the
  machine doesn't have Unix sockets.
not listening on any socket seems to focus on the first case, could
not bind to any socket focuses on the second.  Can we cover both?

Please revise, and update the docs too.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [PATCHES] [HACKERS] listening addresses

2004-03-21 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes:
 This patch attempts to implement the idea, with safety in case the 
 packet is not immediately available.

Seems like you ought to be testing for failure returns from send() and
recv().  Also, what of EINTR from select()?

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html


Re: [PATCHES] change output of \dp

2004-03-21 Thread Bruce Momjian

Newest version of patch applied.  Thanks.

Handles views and sequences.

---


Euler Taveira de Oliveira wrote:
 Hi,
 
 I just noticed that \dp outputs Table to indicate relations (tables, sequences and 
 views) instead of Relation or Name. This patch just correct it, using Name  
 and attaching its Type.
 
 Without the patch:
 
 teste=# \d
  List of relations
  Schema |  Name  |   Type   | Owner
 ++--+---
  public | ab | sequence | euler
  public | foo| table| euler
  public | foobar | view | euler
  public | teste  | table| euler
 (4 rows)
 
 teste=# \dp
   Access privileges for database teste
  Schema | Table  |  Access privileges
 ++-
  public | ab | {euler=a*r*w*d*R*x*t*/euler,teste=ar/euler}
  public | foo| {euler=a*r*w*d*R*x*t*/euler,teste=ar/euler}
  public | foobar |
  public | teste  | {euler=a*r*w*d*R*x*t*/euler,teste=ar/euler}
 (4 rows)
 
 And with the patch:
 
 teste=# \dp
   Access privileges for database teste
  Schema |  Name  |   Type   |  Access privileges
 ++--+-
  public | ab | sequence | {euler=a*r*w*d*R*x*t*/euler,teste=ar/euler}
  public | foo| table| {euler=a*r*w*d*R*x*t*/euler,teste=ar/euler}
  public | foobar | view |
  public | teste  | table| {euler=a*r*w*d*R*x*t*/euler,teste=ar/euler}
 (4 rows)
 
 Please apply it under HEAD, and if it's convenient, put it under 7_4 Branch.
 
 Regards,
 
 -- 
 Euler Taveira de Oliveira
 euler (at) ufgnet.ufg.br
 Desenvolvedor Web e Administrador de Sistemas
 UFGNet - Universidade Federal de Goi?s

[ Attachment, skipping... ]

 
 ---(end of broadcast)---
 TIP 6: Have you searched our list archives?
 
http://archives.postgresql.org

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [PATCHES] change output of \dp

2004-03-21 Thread Bruce Momjian

This is the one applied.

---

Euler Taveira de Oliveira wrote:
 Hi Bruce,
 
  
  Sounds good.  Do you want your original patch applied?
  
 Sorry for the delay, i just redo the patch and change some documentation. Please 
 apply the attached patch.
 I will change the discussion for -hackers about some ideas to improve access 
 privileges output.
 
 Regards,
 
 -- 
 Euler Taveira de Oliveira
 euler (at) ufgnet.ufg.br
 Desenvolvedor Web e Administrador de Sistemas
 UFGNet - Universidade Federal de Goi?s

[ Attachment, skipping... ]

 
 ---(end of broadcast)---
 TIP 8: explain analyze is your friend

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [PATCHES] [HACKERS] libpq thread safety

2004-03-21 Thread Bruce Momjian

I could not get this patch to compile.  I am getting a failure because
BSD/OS doesn't have pthread_rwlock_wrlock().  I am concerned other
platforms might not have it either.

The compile failure is:

gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -O1 
-Wall -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wcast-align -fpic 
-I. -I../../../src/include -I/usr/local/include/readline -I/usr/contrib/include  
-DFRONTEND -DSYSCONFDIR='/usr/local/pgsql/etc'  -c -o fe-secure.o fe-secure.c
fe-secure.c:848: syntax error before `*'
fe-secure.c:848: warning: type defaults to `int' in declaration of `pq_lockarray'
fe-secure.c:848: warning: data definition has no type or storage class
fe-secure.c: In function `pq_lockingcallback':
fe-secure.c:853: warning: implicit declaration of function `pthread_rwlock_wrlock'
fe-secure.c:855: warning: implicit declaration of function `pthread_rwlock_unlock'
fe-secure.c: In function `init_ssl_system':
fe-secure.c:875: `pthread_rwlock_t' undeclared (first use in this function)
fe-secure.c:875: (Each undeclared identifier is reported only once
fe-secure.c:875: for each function it appears in.)
fe-secure.c:881: warning: implicit declaration of function `pthread_rwlock_init'
gmake: *** [fe-secure.o] Error 1


---

Manfred Spraul wrote:
 Bruce Momjian wrote:
 
 Your patch has been added to the PostgreSQL unapplied patches list at:
 
  http://momjian.postgresql.org/cgi-bin/pgpatches
 
 I will try to apply it within the next 48 hours.
   
 
 You are too fast: the patch was a proof of concept, not really tested 
 (actually quite buggy).
 Attached are two patches:
 
 - ready-sigpipe: check_sigpipe_handler skips pthread_create_key if a 
 signal handler was installed. This is wrong - the key is always required.
 - ready-locking: locking around kerberos and openssl.
 
 The patches pass the regression tests on i386 linux. Kerberos is 
 untested, ssl only partially tested due to the lack of a test setup.
 I'm still not sure if the new code is the right thing for the openssl 
 initialization: libpq calls SSL_library_init() unconditionally. If the 
 calling app uses ssl, too, this might confuse openssl.
 
 Could you replace my initial proposal with these two patches?
 
 Btw, is it intentional that THREAD_SUPPORT is not set in src/template/linux?
 
 --
 Manfred

 Index: src/backend/libpq/md5.c
 ===
 RCS file: /projects/cvsroot/pgsql-server/src/backend/libpq/md5.c,v
 retrieving revision 1.22
 diff -c -r1.22 md5.c
 *** src/backend/libpq/md5.c   29 Nov 2003 19:51:49 -  1.22
 --- src/backend/libpq/md5.c   14 Mar 2004 10:46:54 -
 ***
 *** 271,277 
   static void
   bytesToHex(uint8 b[16], char *s)
   {
 ! static char *hex = 0123456789abcdef;
   int q,
   w;
   
 --- 271,277 
   static void
   bytesToHex(uint8 b[16], char *s)
   {
 ! static const char *hex = 0123456789abcdef;
   int q,
   w;
   
 Index: src/interfaces/libpq/fe-auth.c
 ===
 RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-auth.c,v
 retrieving revision 1.89
 diff -c -r1.89 fe-auth.c
 *** src/interfaces/libpq/fe-auth.c7 Jan 2004 18:56:29 -   1.89
 --- src/interfaces/libpq/fe-auth.c14 Mar 2004 10:46:55 -
 ***
 *** 590,595 
 --- 590,596 
   
   case AUTH_REQ_KRB4:
   #ifdef KRB4
 + pglock_thread();
   if (pg_krb4_sendauth(PQerrormsg, conn-sock,
  (struct sockaddr_in *)  
 conn-laddr.addr,
  (struct sockaddr_in *)  
 conn-raddr.addr,
 ***
 *** 597,604 
 --- 598,607 
   {
   snprintf(PQerrormsg, PQERRORMSG_LENGTH,
   libpq_gettext(Kerberos 4 authentication 
 failed\n));
 + pgunlock_thread();
   return STATUS_ERROR;
   }
 + pgunlock_thread();
   break;
   #else
   snprintf(PQerrormsg, PQERRORMSG_LENGTH,
 ***
 *** 608,620 
 --- 611,626 
   
   case AUTH_REQ_KRB5:
   #ifdef KRB5
 + pglock_thread();
   if (pg_krb5_sendauth(PQerrormsg, conn-sock,
hostname) != 
 STATUS_OK)
   {
   snprintf(PQerrormsg, PQERRORMSG_LENGTH,
   libpq_gettext(Kerberos 5 authentication 
 failed\n));
 +   

Re: [PATCHES] [pgsql-hackers-win32] xlog.c timezone name size

2004-03-21 Thread Bruce Momjian

I have increased the str_time() static variable length to 128.  Thanks.

---

Korea PostgreSQL Users' Group wrote:
 On multibyte language locale environment of win32, size of %Z of localtime() 
 function is bigger more then 12 bytes.
 
 so, I suggest that change str_time() function in src/backend/access/transam/xlog.c 
 (2765 line)
 
 buf char array size must be at least 70 bytes (20 bytes = datetime, 50 bytes = 
 tzname of depended local locale(?))
 
 Current str_time() function do not return new line on korean language win32 
 environment.
 It's same on CJK.
 ---(end of broadcast)---
 TIP 4: Don't 'kill -9' the postmaster
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [PATCHES] pstrndup()

2004-03-21 Thread Bruce Momjian

Karel, do you plan to use pstrndup for some purpose?  I assume so.

---

Karel Zak wrote:
 
  Hi guys,
 
  we have pstrdup(char *string) and this tiny patch adds 
  pstrndup(char *sting, Size len).
 
  By the  way, I  a little  played with the  apache memory  managment and
  they  have the  others interesting  routines like  ap_pstrcat(...) that
  concatenate  all  arguments  (last  must  be  NULL)  to  new  allocated
  string. Is something like this interesting for PostgreSQL?
 
 Karel
 
 -- 
  Karel Zak  [EMAIL PROTECTED]
  http://home.zf.jcu.cz/~zakkr/

[ Attachment, skipping... ]

 
 ---(end of broadcast)---
 TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [PATCHES] pstrndup()

2004-03-21 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
 Karel, do you plan to use pstrndup for some purpose?  I assume so.

I am not familiar with strndup.  If the spec is like strncpy, I would
vote against including it ... strncpy is so broken that we had to invent
our own variant ...

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [PATCHES] [HACKERS] 7.4.2 Build broken on (Sparc) Solaris 7 and 8

2004-03-21 Thread Bruce Momjian
Jim Seymour wrote:
 Bruce Momjian [EMAIL PROTECTED] wrote:
  
 [snip]
  
  OK, patch attached and applied.  It adds configure tests for the 5-arg
  version of getpwuid_r() and properly falls back to the Posix draft
  version you have on Solaris.  Seems Solaris 9 also still has the draft
  version.
 [snip]
 
 Well, yes and no.  If you define _POSIX_PTHREAD_SEMANTICS, you get the
 5-arg version.  It looks like this has been the case at least back to
 Solaris 2.5.1.
 
 I didn't really expect anything prior to 2.5.1 to be an issue, so I
 didn't bother looking into fixes for anything beyond that.

Oh, very interesting.  CVS HEAD has in template/solaris:

# tools/thread/thread_test must be run
if test $GCC = yes
thenTHREAD_CPPFLAGS=-D_POSIX_PTHREAD_SEMANTICS
THREAD_LIBS=-pthread
elseTHREAD_CPPFLAGS=-mt -D_POSIX_PTHREAD_SEMANTICS
THREAD_LIBS=-lpthread
fi

I added the -D_POSIX_PTHREAD_SEMANTICS  flags into post-7.4.2, so it
seems this platform would work even without checking for the 4-arg
getpwuid_r version.  However, I noticed that 'man getpwuid_r' only
mentions the 4-arg version.

I will leave the 4-arg check in. The original author thought it might be
needed, and the Solaris manual mentions it, so odds are some other
platforms will hit it too, and perhaps not have the 5-arg version.

Thanks for the research.  I will add a mention in the solaris template
file.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html


Re: [PATCHES] [HACKERS] UnixWare/CVS Tip/initdb.c needs to use threads

2004-03-21 Thread Bruce Momjian
Larry Rosenman wrote:
-- Start of PGP signed section.
 [moved to -patches because of the patch]
 
 
 --On Friday, March 19, 2004 08:01:53 -0500 Bruce Momjian 
 [EMAIL PROTECTED] wrote:
 
  Larry Rosenman wrote:
   I thought that once you include libpthread in libpq, that you don't
   have to mention it again then you use libpq.  Is your platform
   different somehow in this regard?
  
   I seem to remember this problem with libcrypt and libpq.  Is this the
   same problem?
  
   I see that initdb is just the first of many /bin programs to be
   compiled, so if we have to add the thread lib, we will have to do it
   for all the bin programs.  Yikes.  Why wasn't this a problem for 7.4?
  7.4 had initdb as a Shell Script.
  the 7.4.x libpq didn't have any pthread_* references in it, that I see
  on my box.
 
  Ah, yes.  We added the thread-local storage to handle SIGPIPE.  The
  problem is that initdb isn't the only place.  If you comment out initdb
  from the Makefile in src/bin, does the next make fail too?  I bet it
  does.
 
 Apparently, because of the way the wrappers work, having -lpthread on 
 libpq.so does NOT add it to the NEEDED list.

Clarification.  The flags are -pthread or -K pthread, not -lpthread,
which is clearly a linker flag.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [PATCHES] [HACKERS] libpq thread safety

2004-03-21 Thread Manfred Spraul
Bruce Momjian wrote:

I could not get this patch to compile.  I am getting a failure because
BSD/OS doesn't have pthread_rwlock_wrlock().  I am concerned other
platforms might not have it either.
 

I feared that. I'll switch to pthread_mutex_lock()+_unlock().
pthread_rwlock_wrlock()+_unlock was faster in some tests - wrlocks do 
not need to be async signal safe.

I'll send a new patch.
--
   Manfred
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [PATCHES] pstrndup()

2004-03-21 Thread Karel Zak
On Sun, Mar 21, 2004 at 11:45:18PM -0500, Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  Karel, do you plan to use pstrndup for some purpose?  I assume so.

 I   thinkPostgreSQL   should   supports   basicoperation   with
 allocation/strings if  it's open for  users' C functions and  we expect
 our own memory system usage.

 I am not familiar with strndup.  If the spec is like strncpy, I would
 vote against including it ... strncpy is so broken that we had to invent
 our own variant ...

 POSIX strncpy()  is different,  a result from  strncpy needn't  be zero
 terminated. You're right it's horrible function.
 
 The result of  strndup() is always zero terminated. It's  more safe and
 strndup() is  binary safe because  it doesn't check something  in input
 string. The pstrndup() is based on PostgreSQL memory managment.

Karel

-- 
 Karel Zak  [EMAIL PROTECTED]
 http://home.zf.jcu.cz/~zakkr/

---(end of broadcast)---
TIP 8: explain analyze is your friend