CVS tip built on Debian unstable, i386, Linux 2.6.5 SMP.
gcc 3.3.3

./configure --with-openssl  --with-pam --with-krb5 --with-gnu-ld
--with-python --with-perl --with-tcl --with-pgport=5342
--enable-thread-safety --enable-nls --enable-integer-datetimes 
--enable-debug --enable-cassert --enable-depend

1.  There are regression failures on timestamptz and horology which seem
to have come about either on input or output of timestamps with
fractional seconds.  I tried various inputs and found that certain
timestamps with fractional seconds had one second added to the time. 
This appears to be confined to the period from midnight at the start of
Dec 14 1901 GMT to midnight at the start of Jan 01 2000 GMT

junk=# select cast('Dec 13 15:59:59.50 1901 PST' as timestamptz);
      timestamptz
------------------------
 1901-12-13 23:59:59.50
(1 row)
 
junk=# select cast('Dec 13 16:00:59.50 1901 PST' as timestamptz);
        timestamptz
---------------------------
 1901-12-14 00:01:00.50+00
(1 row) 
 
junk=# select cast('Dec 13 23:59:59.50 1901 GMT' as timestamptz);
      timestamptz
------------------------
 1901-12-13 23:59:59.50
(1 row)
 
junk=# select cast('Dec 14 00:00:00.50 1901 GMT' as timestamptz);
        timestamptz
---------------------------
 1901-12-14 00:00:01.50+00
(1 row)

I tried debugging this but got a segmentation fault and apparent stack
corruption in gdb, with the reported break point not anywhere I had set
one.  I don't know what to do about that.


2.  If the postmaster is not running, there is garbage in psql's error
message:

olly@linda$ export PGPORT=5342
olly@linda$ export PATH=/usr/local/pgsql/bin:$PATH
olly@linda$ psql junk
psql: could not connect to server: ,*@È        %@
        Is the server running locally and accepting
        connections on Unix domain socket "/tmp/.s.PGSQL.5342"?

olly@linda$ psql -h localhost junk
psql: could not connect to server: ,*@È        %@
        Is the server running on host "localhost" and accepting
        TCP/IP connections on port 5342?


3.  There is a compilation warning that a constant will not fit into a
long in adt.c.  There are two more files where INT64CONST() is required
but not supplied.  Patch attached.

-- 
Oliver Elphick                                          olly@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA  92C8 39E7 280E 3631 3F0E  1EC0 5664 7A2F A543 10EA
                 ========================================
     "Do all things without murmurings and disputings; 
      that ye may be blameless and harmless, the sons of 
      God, without rebuke, in the midst of a crooked and 
      perverse nation, among whom ye shine as lights in the 
      world."    Philippians 2:14,15
Sun, 30 May 2004 22:53:12 +0100
Oliver Elphick <olly@lfix.co.uk>
CVS tip problems
Oliver Elphick <olly@lfix.co.uk> writes:
> 1.  There are regression failures on timestamptz and horology which seem
> to have come about either on input or output of timestamps with
> fractional seconds.

Hmm ... I'm seeing slightly different misbehaviors in the
integer-datetimes and float-datetimes cases.  I think we are about to
have to dig down to the root of the off-by-one-second cases that Tom
Lockhart noticed but never really solved.  I suspect that the issue has
to do with platform-specific rounding of negative values to integer, but
I haven't got the full story quite yet.

> I tried debugging this but got a segmentation fault and apparent stack
> corruption in gdb, with the reported break point not anywhere I had set
> one.  I don't know what to do about that.

Recompiling with -O0 might help debuggability.

> 2.  If the postmaster is not running, there is garbage in psql's error
> message:

Works OK for me --- could you trace that one more fully?

> 3.  There is a compilation warning that a constant will not fit into a
> long in adt.c.  There are two more files where INT64CONST() is required
> but not supplied.  Patch attached.

Not sure about these ... does anyone else get these warnings?

			regards, tom lane

Mon, 31 May 2004 02:31:14 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: CVS tip problems 
Oliver Elphick <olly@lfix.co.uk> writes:
> 1.  There are regression failures on timestamptz and horology which seem
> to have come about either on input or output of timestamps with
> fractional seconds.

I believe I've fixed this.

> 2.  If the postmaster is not running, there is garbage in psql's error
> message:

I can't duplicate that here.  It looks to me like the probable
explanation is a broken or incompatible version of strerror_r() on your
machine.  Does the failure go away if you build without thread-safety?

> 3.  There is a compilation warning that a constant will not fit into a
> long in adt.c.  There are two more files where INT64CONST() is required
> but not supplied.  Patch attached.

Patch applied, thanks.

			regards, tom lane

Mon, 31 May 2004 14:55:23 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: CVS tip problems 
On Mon, 2004-05-31 at 19:55, Tom Lane wrote:
> Oliver Elphick <olly@lfix.co.uk> writes:
> > 1.  There are regression failures on timestamptz and horology which seem
> > to have come about either on input or output of timestamps with
> > fractional seconds.
> 
> I believe I've fixed this.

All regression tests pass now.

> > 2.  If the postmaster is not running, there is garbage in psql's error
> > message:
> 
> I can't duplicate that here.  It looks to me like the probable
> explanation is a broken or incompatible version of strerror_r() on your
> machine.  Does the failure go away if you build without thread-safety?

Yes it does.

I'll see if I can run with a debugging libc and find it.

-- 
Oliver Elphick                                          olly@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA  92C8 39E7 280E 3631 3F0E  1EC0 5664 7A2F A543 10EA
                 ========================================
     "How precious also are thy thoughts unto me, O God! how
      great is the sum of them! If I should count them, they
      are more in number than the sand; when I awake, I am 
      still with thee."    Psalms 139: 17,18 


Mon, 31 May 2004 21:36:12 +0100
Oliver Elphick <olly@lfix.co.uk>
Re: CVS tip problems
Oliver Elphick <olly@lfix.co.uk> writes:
> On Mon, 2004-05-31 at 19:55, Tom Lane wrote:
>> I can't duplicate that here.  It looks to me like the probable
>> explanation is a broken or incompatible version of strerror_r() on your
>> machine.  Does the failure go away if you build without thread-safety?

> Yes it does.
> I'll see if I can run with a debugging libc and find it.

First you might want to check which flavor of strerror_r() your platform
has --- does it return int or char* ?  The Linux man page for
strerror_r() says

   strerror_r() with prototype as given above is specified by  SUSv3,  and
   was  in  use  under Digital Unix and HP Unix. An incompatible function,
   with prototype

       char *strerror_r(int errnum, char *buf, size_t n);

   is a GNU extension used by glibc (since 2.0), and must be  regarded  as
   obsolete  in view of SUSv3.  The GNU version may, but need not, use the
   user-supplied buffer.  If it does, the result may be truncated in  case
   the  supplied buffer is too small. The result is always NUL-terminated.

The code we have appears to assume that the result will always be placed
in the user-supplied buffer, which is apparently NOT what the glibc
version does.

			regards, tom lane

Mon, 31 May 2004 20:33:55 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: CVS tip problems 
Tom Lane wrote:
> Oliver Elphick <olly@lfix.co.uk> writes:
> > On Mon, 2004-05-31 at 19:55, Tom Lane wrote:
> >> I can't duplicate that here.  It looks to me like the probable
> >> explanation is a broken or incompatible version of strerror_r() on your
> >> machine.  Does the failure go away if you build without thread-safety?
> 
> > Yes it does.
> > I'll see if I can run with a debugging libc and find it.
> 
> First you might want to check which flavor of strerror_r() your platform
> has --- does it return int or char* ?  The Linux man page for
> strerror_r() says
> 
>    strerror_r() with prototype as given above is specified by  SUSv3,  and
>    was  in  use  under Digital Unix and HP Unix. An incompatible function,
>    with prototype
> 
>        char *strerror_r(int errnum, char *buf, size_t n);
> 
>    is a GNU extension used by glibc (since 2.0), and must be  regarded  as
>    obsolete  in view of SUSv3.  The GNU version may, but need not, use the
>    user-supplied buffer.  If it does, the result may be truncated in  case
>    the  supplied buffer is too small. The result is always NUL-terminated.
> 
> The code we have appears to assume that the result will always be placed
> in the user-supplied buffer, which is apparently NOT what the glibc
> version does.

What does "may, but need not, use the user-supplied buffer" supposed to
mean in practical terms.  How do they expect us to use it?

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

Mon, 31 May 2004 22:01:34 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: CVS tip problems
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> The code we have appears to assume that the result will always be placed
>> in the user-supplied buffer, which is apparently NOT what the glibc
>> version does.

> What does "may, but need not, use the user-supplied buffer" supposed to
> mean in practical terms.  How do they expect us to use it?

AFAICS they expect you to use the function's return value.

The current PG code is really erroneous for *both* strerror_r specs,
since the SUS-spec version doesn't promise to put anything into the
buffer if it returns a failure code.  I think you will have to write
some autoconf code to detect which return type is provided, and do
the right things with the return value in both cases.

			regards, tom lane

Mon, 31 May 2004 22:10:04 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: CVS tip problems 
On Tue, 2004-06-01 at 01:33, Tom Lane wrote:
> First you might want to check which flavor of strerror_r() your platform
> has --- does it return int or char* ?  The Linux man page for
> strerror_r() says

>From the definition in /usr/include/string.h, glibc 2.3.2 still has the
version that returns char* 

-- 
Oliver Elphick                                          olly@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA  92C8 39E7 280E 3631 3F0E  1EC0 5664 7A2F A543 10EA
                 ========================================
     "Thou will show me the path of life; in thy presence 
      is fullness of joy; at thy right hand there are  
      pleasures for evermore."         Psalms 16:11 


Tue, 01 Jun 2004 06:29:40 +0100
Oliver Elphick <olly@lfix.co.uk>
Re: CVS tip problems
On Tue, 2004-06-01 at 01:33, Tom Lane wrote:
> First you might want to check which flavor of strerror_r() your platform
> has --- does it return int or char* ?  

I made the following change to the strerror_r call, which makes it work
correctly with threading enabled:

--- src/port/thread.c   23 Apr 2004 18:15:55 -0000      1.20
+++ src/port/thread.c   1 Jun 2004 07:18:26 -0000
@@ -71,7 +71,8 @@
 #if defined(FRONTEND) && defined(ENABLE_THREAD_SAFETY) && defined(HAVE_STRERROR_R)
        /* reentrant strerror_r is available */
        /* some early standards had strerror_r returning char * */
-       strerror_r(errnum, strerrbuf, buflen);
+       char buf[256];
+       StrNCpy(strerrbuf, strerror_r(errnum, buf, 256), buflen);
        return strerrbuf;
                                                                                
 #else


(I realise this is not sufficient for a patch to correct the problem.)
-- 
Oliver Elphick                                          olly@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA  92C8 39E7 280E 3631 3F0E  1EC0 5664 7A2F A543 10EA
                 ========================================
     "Thou will show me the path of life; in thy presence 
      is fullness of joy; at thy right hand there are  
      pleasures for evermore."         Psalms 16:11 


Tue, 01 Jun 2004 08:23:07 +0100
Oliver Elphick <olly@lfix.co.uk>
Re: CVS tip problems
Oliver Elphick <olly@lfix.co.uk> writes:
> -       strerror_r(errnum, strerrbuf, buflen);
> +       char buf[256];
> +       StrNCpy(strerrbuf, strerror_r(errnum, buf, 256), buflen);
>         return strerrbuf;

Easier and safer would be

> -       strerror_r(errnum, strerrbuf, buflen);
> -       return strerrbuf;
> +       return strerror_r(errnum, strerrbuf, buflen);

The real point here is that we need to code differently depending on
which flavor of strerror_r we have.

			regards, tom lane

Tue, 01 Jun 2004 09:51:11 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: CVS tip problems 
This patch fixes strerror_r() by checking the return type from
configure.

---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> The code we have appears to assume that the result will always be placed
> >> in the user-supplied buffer, which is apparently NOT what the glibc
> >> version does.
> 
> > What does "may, but need not, use the user-supplied buffer" supposed to
> > mean in practical terms.  How do they expect us to use it?
> 
> AFAICS they expect you to use the function's return value.
> 
> The current PG code is really erroneous for *both* strerror_r specs,
> since the SUS-spec version doesn't promise to put anything into the
> buffer if it returns a failure code.  I think you will have to write
> some autoconf code to detect which return type is provided, and do
> the right things with the return value in both cases.
> 
> 			regards, tom lane
> 

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

Index: configure
===================================================================
RCS file: /cvsroot/pgsql-server/configure,v
retrieving revision 1.371
diff -c -c -r1.371 configure
*** configure	28 May 2004 20:52:41 -0000	1.371
--- configure	7 Jun 2004 22:21:45 -0000
***************
*** 13759,13764 ****
--- 13759,13817 ----
  
  fi
  
+ echo "$as_me:$LINENO: checking whether strerror_r returns int" >&5
+ echo $ECHO_N "checking whether strerror_r returns int... $ECHO_C" >&6
+ if test "${pgac_func_strerror_r_int+set}" = set; then
+   echo $ECHO_N "(cached) $ECHO_C" >&6
+ else
+   cat >conftest.$ac_ext <<_ACEOF
+ #line $LINENO "configure"
+ #include "confdefs.h"
+ #include <string.h>
+ #ifdef F77_DUMMY_MAIN
+ #  ifdef __cplusplus
+      extern "C"
+ #  endif
+    int F77_DUMMY_MAIN() { return 1; }
+ #endif
+ int
+ main ()
+ {
+ int strerror_r(int, char *, size_t);
+   ;
+   return 0;
+ }
+ _ACEOF
+ rm -f conftest.$ac_objext
+ if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+   (eval $ac_compile) 2>&5
+   ac_status=$?
+   echo "$as_me:$LINENO: \$? = $ac_status" >&5
+   (exit $ac_status); } &&
+          { ac_try='test -s conftest.$ac_objext'
+   { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+   (eval $ac_try) 2>&5
+   ac_status=$?
+   echo "$as_me:$LINENO: \$? = $ac_status" >&5
+   (exit $ac_status); }; }; then
+   pgac_func_strerror_r_int=yes
+ else
+   echo "$as_me: failed program was:" >&5
+ cat conftest.$ac_ext >&5
+ pgac_func_strerror_r_int=no
+ fi
+ rm -f conftest.$ac_objext conftest.$ac_ext
+ fi
+ echo "$as_me:$LINENO: result: $pgac_func_strerror_r_int" >&5
+ echo "${ECHO_T}$pgac_func_strerror_r_int" >&6
+ if test x"$pgac_func_strerror_r_int" = xyes ; then
+ 
+ cat >>confdefs.h <<\_ACEOF
+ #define STRERROR_R_INT
+ _ACEOF
+ 
+ fi
+ 
  
  else
  # do not use values from template file
Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql-server/configure.in,v
retrieving revision 1.360
diff -c -c -r1.360 configure.in
*** configure.in	28 May 2004 20:52:42 -0000	1.360
--- configure.in	7 Jun 2004 22:21:53 -0000
***************
*** 993,998 ****
--- 993,999 ----
  LIBS="$_LIBS"
  
  PGAC_FUNC_GETPWUID_R_5ARG
+ PGAC_FUNC_STRERROR_R_INT
  
  else
  # do not use values from template file
Index: config/c-library.m4
===================================================================
RCS file: /cvsroot/pgsql-server/config/c-library.m4,v
retrieving revision 1.25
diff -c -c -r1.25 c-library.m4
*** config/c-library.m4	20 Mar 2004 15:39:27 -0000	1.25
--- config/c-library.m4	7 Jun 2004 22:21:53 -0000
***************
*** 96,101 ****
--- 96,118 ----
  ])# PGAC_FUNC_GETPWUID_R_5ARG
  
  
+ # PGAC_FUNC_STRERROR_R_INT
+ # ---------------------------
+ # Check if strerror_r() returns an int (SUSv3) rather than a char * (GNU libc)
+ # If so, define STRERROR_R_INT
+ AC_DEFUN([PGAC_FUNC_STRERROR_R_INT],
+ [AC_CACHE_CHECK(whether strerror_r returns int,
+ pgac_func_strerror_r_int,
+ [AC_TRY_COMPILE([#include <string.h>],
+ [int strerror_r(int, char *, size_t);],
+ [pgac_func_strerror_r_int=yes],
+ [pgac_func_strerror_r_int=no])])
+ if test x"$pgac_func_strerror_r_int" = xyes ; then
+   AC_DEFINE(STRERROR_R_INT,, [Define to 1 if strerror_r() returns a int.])
+ fi
+ ])# PGAC_FUNC_STRERROR_R_INT
+ 
+ 
  # PGAC_UNION_SEMUN
  # ----------------
  # Check if `union semun' exists. Define HAVE_UNION_SEMUN if so.
Index: src/include/pg_config.h.in
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/pg_config.h.in,v
retrieving revision 1.76
diff -c -c -r1.76 pg_config.h.in
*** src/include/pg_config.h.in	22 May 2004 00:34:51 -0000	1.76
--- src/include/pg_config.h.in	7 Jun 2004 22:21:56 -0000
***************
*** 607,612 ****
--- 607,615 ----
  /* Define to 1 if you have the ANSI C header files. */
  #undef STDC_HEADERS
  
+ /* Define to 1 if strerror_r() returns a int. */
+ #undef STRERROR_R_INT
+ 
  /* Define to 1 if your <sys/time.h> declares `struct tm'. */
  #undef TM_IN_SYS_TIME
  
Index: src/port/thread.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/port/thread.c,v
retrieving revision 1.20
diff -c -c -r1.20 thread.c
*** src/port/thread.c	23 Apr 2004 18:15:55 -0000	1.20
--- src/port/thread.c	7 Jun 2004 22:21:56 -0000
***************
*** 70,81 ****
  {
  #if defined(FRONTEND) && defined(ENABLE_THREAD_SAFETY) && defined(HAVE_STRERROR_R)
  	/* reentrant strerror_r is available */
! 	/* some early standards had strerror_r returning char * */
! 	strerror_r(errnum, strerrbuf, buflen);
! 	return strerrbuf;
! 
  #else
- 
  	/* no strerror_r() available, just use strerror */
  	StrNCpy(strerrbuf, strerror(errnum), buflen);
  
--- 70,86 ----
  {
  #if defined(FRONTEND) && defined(ENABLE_THREAD_SAFETY) && defined(HAVE_STRERROR_R)
  	/* reentrant strerror_r is available */
! #ifdef STRERROR_R_INT
! 	/* SUSv3 version */
! 	if (strerror_r(errnum, strerrbuf, buflen) == 0)
! 		return strerrbuf;
! 	else
! 		return NULL;
! #else
! 	/* GNU libc */
! 	return strerror_r(errnum, strerrbuf, buflen);
! #endif
  #else
  	/* no strerror_r() available, just use strerror */
  	StrNCpy(strerrbuf, strerror(errnum), buflen);
Mon, 7 Jun 2004 18:39:23 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] CVS tip problems
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> ! #ifdef STRERROR_R_INT
> ! 	/* SUSv3 version */
> ! 	if (strerror_r(errnum, strerrbuf, buflen) == 0)
> ! 		return strerrbuf;
> ! 	else
> ! 		return NULL;
> ! #else

This code will dump core if strerror_r ever fails, which seems like
a bad idea.  I suggest that it be like

! 	if (strerror_r(errnum, strerrbuf, buflen) == 0)
! 		return strerrbuf;
! 	else
! 		return "strerror_r failed";

which at least gives a hint of the problem ...

			regards, tom lane

Mon, 07 Jun 2004 18:45:07 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] CVS tip problems 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > ! #ifdef STRERROR_R_INT
> > ! 	/* SUSv3 version */
> > ! 	if (strerror_r(errnum, strerrbuf, buflen) == 0)
> > ! 		return strerrbuf;
> > ! 	else
> > ! 		return NULL;
> > ! #else
> 
> This code will dump core if strerror_r ever fails, which seems like
> a bad idea.  I suggest that it be like
> 
> ! 	if (strerror_r(errnum, strerrbuf, buflen) == 0)
> ! 		return strerrbuf;
> ! 	else
> ! 		return "strerror_r failed";
> 
> which at least gives a hint of the problem ...

I assume all the callers have to check for NULL, rather than supply a
dummy string.  However, are you saying that this is more of a debug tool
and should never fail to return a usable value?

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

Mon, 7 Jun 2004 18:46:30 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] CVS tip problems
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I assume all the callers have to check for NULL,

Eh?  *None* of the callers of pqStrerror check for NULL, and I don't
think they should have to.  We surely do not check for null return from
plain strerror() anyplace.

			regards, tom lane

Mon, 07 Jun 2004 19:00:51 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] CVS tip problems 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I assume all the callers have to check for NULL,
> 
> Eh?  *None* of the callers of pqStrerror check for NULL, and I don't
> think they should have to.  We surely do not check for null return from
> plain strerror() anyplace.

Oh, I see.  It should be like strerror().  Makes sense. I replaced NULL
with "Unknown error" which is what strerror does for an unknown error
number.

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

Mon, 7 Jun 2004 21:46:30 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] CVS tip problems