Bruce Momjian writes:
> The only guess I have is that select() is modifying the timeout
> structure on return, but I didn't think it did that, does it?
You shouldn't assume so; I think it does on some platforms. The Single
Unix Spec says
On successful completion, the object pointed to b
Interesting. Here is the patch I just applied:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c.diff?r1=1.116&r2=1.117
The only guess I have is that select() is modifying the timeout
structure on return, but I didn't think it did that, does it?
Googling
> -Original Message-
> From: Stephen Frost [mailto:[EMAIL PROTECTED]
> Sent: 28 June 2005 18:30
> To: Dave Page
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] CVS tip build failure (win32)
>
> * Dave Page (dpage@vale-housing.co.uk) wrote:
> > I
* Dave Page (dpage@vale-housing.co.uk) wrote:
> I'm seeing the following failure on win32, post roles patch application:
[...]
> 'InitializeAcl'
[...]
> That's following a cvs update and a make clean. All was fine before I
> updated :-(
Wow. Apparently 'InitializeAcl' is part of the Windows API.
"Dave Page" writes:
> ../../../src/include/utils/acl.h:214: error: conflicting types for
> 'InitializeAcl'
> c:/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/winbase.h:1571
> : error: previous declaration of 'InitializeAcl' was here
Grumble. I'll change the routine name. Thanks...
seems to have fixed my arm problem that you (Tom) looking into the other day.
Jim
-- Original Message ---
From: Tom Lane <[EMAIL PROTECTED]>
To: Darcy Buskermolen <[EMAIL PROTECTED]>
Cc: pgsql-hackers@postgresql.org
Sent: Wed, 26 Jan 2005 13:50:11 -0500
Subject:
Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> It looks like teodor's latest commits to tseach2 has broken building on SPARC
> solaris 8.
HPUX, too. Patch committed.
regards, tom lane
---(end of broadcast)---
TIP 3: if po
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
On my FC3 installation, there is a /usr/lib/libpython2.3.so.1.0
... do you have anything comparable?
No, except the non-standard one on the openoffice libs. Building as shared
lib only became a part of standard python in rel
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>> On my FC3 installation, there is a /usr/lib/libpython2.3.so.1.0
>> ... do you have anything comparable?
> No, except the non-standard one on the openoffice libs. Building as shared
> lib only became a part of standard python in release 2.3 - see
> ht
Tom Lane said:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> The last REL7_4_STABLE build the machine did had this:
>
>> ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
>> -Wmissing-declarations -fpic -shared -Wl,-soname,libplpython.so.0
>> plpython.o -L../../../src/port -L/usr
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The last REL7_4_STABLE build the machine did had this:
> ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
> -Wmissing-declarations -fpic -shared -Wl,-soname,libplpython.so.0
> plpython.o -L../../../src/port -L/usr/lib/python2.2/confi
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
A couple of hours ago things started breaking thus, I assume related to
the Makefile changes made around then:
ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -shared -Wl,-soname,l
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> A couple of hours ago things started breaking thus, I assume related to
> the Makefile changes made around then:
> ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
> -Wmissing-declarations -fpic -shared -Wl,-soname,libplpython.so.0 pl
Oliver Elphick <[EMAIL PROTECTED]> 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);
> -
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 Ap
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
Bruce Momjian <[EMAIL PROTECTED]> 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 practica
Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> 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 y
Oliver Elphick <[EMAIL PROTECTED]> 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-sa
On Mon, 2004-05-31 at 19:55, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> 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 reg
Oliver Elphick <[EMAIL PROTECTED]> 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
Shridhar Daithankar wrote:
> On Sunday 30 May 2004 19:37, Bruce Momjian wrote:
> > > The relevant configure messages read
> > > -
> > > checking whether pthreads work without any flags... no
> > > checking whether pthreads work with -Kthread... no
> > > checking whether pthreads work wi
On Sunday 30 May 2004 19:37, Bruce Momjian wrote:
> > The relevant configure messages read
> > -
> > checking whether pthreads work without any flags... no
> > checking whether pthreads work with -Kthread... no
> > checking whether pthreads work with -kthread... no
> > checking for the
Oliver Elphick <[EMAIL PROTECTED]> 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-dateti
Shridhar Daithankar wrote:
> Hi,
>
> Platform Slackware linux 9.1/ Linux 2.6.4
>
> I did a make distclean and ./configure --enable-thread-safety. The build
> aborted with following error messages
>
> make[4]: Leaving directory `/home/shridhar/postgresql/pgsql/src/port'
> gcc -O2 -fno-strict-ali
Sean Chittenden <[EMAIL PROTECTED]> writes:
>> Does anyone know if FreeBSD 3.* or before still exist in the wild?
>> We might have to tweak the pattern to match those too.
> Ehh it probably does. I get emails once every 2-3 mo from
> someone running it on a 2.x box and that code's probably 6
> >> We could change
> >> float8/i.86-.*-freebsd=3Dfloat8-small-is-zero
> >> to
> >> float8/i.86-.*-freebsd4=3Dfloat8-small-is-zero
>
> > This change compiles / regresses fine for me, but I didn't read the
> > whole thread to try to see what to look for.
>
> Good enough --- change committed.
>
>
Rod Taylor <[EMAIL PROTECTED]> writes:
>> We could change
>> float8/i.86-.*-freebsd=3Dfloat8-small-is-zero
>> to
>> float8/i.86-.*-freebsd4=3Dfloat8-small-is-zero
> This change compiles / regresses fine for me, but I didn't read the
> whole thread to try to see what to look for.
Good enough --- c
> > > We could change
> > > float8/i.86-.*-freebsd=float8-small-is-zero
> > > to
> > > float8/i.86-.*-freebsd4=float8-small-is-zero
>
> This change compiles / regresses fine for me, but I didn't read the
> whole thread to try to see what to look for.
FreeBSD 5.1 imported gdtoa which fixed the
> > We could change
> > float8/i.86-.*-freebsd=float8-small-is-zero
> > to
> > float8/i.86-.*-freebsd4=float8-small-is-zero
This change compiles / regresses fine for me, but I didn't read the
whole thread to try to see what to look for.
--
Rod Taylor <[EMAIL PROTECTED]>
PGP Key: http://
> > Tom, you said you needed a shell way of detecting this, does the
> > following work?
>
> No, I need something that will work in the regression test
> resultmap, which basically only knows about the platform identifier
> string computed by config.guess.
>
> We could change
> float8/i.86-
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Tom, you said you needed a shell way of detecting this, does the
> following work?
No, I need something that will work in the regression test resultmap,
which basically only knows about the platform identifier string
computed by config.guess.
We could
> > >> checking for struct sockaddr_storage... no
> >
> > > Hrm on 5.1-CURRENT (~3 days old) it works:
> >
> > When did you last update from our CVS? I corrected the configure test
> > a couple hours ago ...
>
> Oh err, umm 'bout 10minutes ago I Sup'ed and checked.
>
> *wanders o
> >> checking for struct sockaddr_storage... no
>
> > Hrm on 5.1-CURRENT (~3 days old) it works:
>
> When did you last update from our CVS? I corrected the configure test
> a couple hours ago ...
Oh err, umm 'bout 10minutes ago I Sup'ed and checked.
*wanders off to go read -commi
Sean Chittenden <[EMAIL PROTECTED]> writes:
>> checking for struct sockaddr_storage... no
> Hrm on 5.1-CURRENT (~3 days old) it works:
When did you last update from our CVS? I corrected the configure test
a couple hours ago ...
regards, tom lane
---
> It would seem the configure test isn't picking up on the structure.
>
> checking sys/socket.h usability... yes
> checking sys/socket.h presence... yes
> checking for sys/socket.h... yes
> <--snip-->
> checking for struct sockaddr_storage... no
Hrm on 5.1-CURRENT (~3 days old) it works:
ch
Rod Taylor <[EMAIL PROTECTED]> writes:
> It would seem the configure test isn't picking up on the structure.
It works here (where "works" is defined as "finds the struct on Linux
and doesn't find it on HPUX" --- both correct according to a search
of /usr/include). You'll need to dig into why it f
It would seem the configure test isn't picking up on the structure.
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
<--snip-->
checking for struct sockaddr_storage... no
FreeBSD sys/socket.h is attached.
Failing configure test below
Seems it was the removal of an include in this commit:
revision 1.145
date: 2003/01/06 09:58:23; author: petere; state: Exp; lines: +1 -2
Fix for systems that don't have INET_ADDRSTRLEN.
netinet/in.h re-added to include list.
--
On Tue, 2003-01-14 at 17:11, Bruce Momjian wrote:
> Any idea what it needs? What is in inet.h at that line, and where is it
> defined? I see sys/socket.h included. Does sys/types.h help?
>
>
> ---
>
> Rod Taylor wrote:
>
Thats the first time I've managed to add the attachment and forget the
message.
inet.h attached in previous email.
On Tue, 2003-01-14 at 17:11, Bruce Momjian wrote:
> Any idea what it needs? What is in inet.h at that line, and where is it
> defined? I see sys/socket.h included. Does sys/types
Any idea what it needs? What is in inet.h at that line, and where is it
defined? I see sys/socket.h included. Does sys/types.h help?
---
Rod Taylor wrote:
-- Start of PGP signed section.
> It appears that FreeBSD doesn't
Rod Taylor <[EMAIL PROTECTED]> writes:
> Hmm.. whelp, the file in question on FreeBSD is sys/time.h (attached
> earlier) so this won't fix it.
Added #include . We seem to use this unconditionally in
many other files, so I don't see a reason not to include it here.
regard
On Sat, 2002-08-17 at 22:44, Bruce Momjian wrote:
>
> I think I added time.h and sys/types.h. That should do it for you.
Hmm.. whelp, the file in question on FreeBSD is sys/time.h (attached
earlier) so this won't fix it.
>
I think I added time.h and sys/types.h. That should do it for you.
---
Rod Taylor wrote:
> On Sat, 2002-08-17 at 22:08, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I am not seeing the failure here on
On Sat, 2002-08-17 at 22:08, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am not seeing the failure here on BSD/OS. I just fixed the
> > libpq-int.h problem. Please update to cvs current and let me know what
> > you see.
>
> FWIW, libpq seems to build fine here (HPUX 10.20)
The code was clearly wrong, mentioning timeval with no time.h nor
sys/types.h include. My patches should fix him [good]. :-)
Who used to say, "I will fix him good"? I don't remember.
---
Tom Lane wrote:
> Bruce Momjian
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am not seeing the failure here on BSD/OS. I just fixed the
> libpq-int.h problem. Please update to cvs current and let me know what
> you see.
FWIW, libpq seems to build fine here (HPUX 10.20) both before and after
your latest commit. Rod should pr
I am not seeing the failure here on BSD/OS. I just fixed the
libpq-int.h problem. Please update to cvs current and let me know what
you see.
---
Rod Taylor wrote:
> n file included from fe-connect.c:24:
> libpq-int.h:337:
On Mon, 1 Oct 2001, Bruce Momjian wrote:
> > > > I would propose that the reference machine be one that one of the
> > > > "committers" owns, and be one whose owner is willing to *always* go
> > > > through the effort to resolve regression test changes and differences.
> > > Er ... wasn't that *y
>> ERROR: operator class "timestamp_ops" does not accept data type
>> timestamp with time zone
> Oh, ye olde change-of-opclass-name problem. I've stuck a hack into
> gram.y as we've done in the past, but I'm starting to think that we
> need a better answer going forward. Maybe pg_dump could be
On Monday 01 October 2001 05:07 pm, Bruce Momjian wrote:
> I think we are all just scrambing to get beta ready while the server
> reconfigures itself. :-) I don't see any fundamental changes being
> proposed. We are trying to plug leaks and are stepping on toes, or at
> least it looks that way
> > > I would propose that the reference machine be one that one of the
> > > "committers" owns, and be one whose owner is willing to *always* go
> > > through the effort to resolve regression test changes and differences.
> > Er ... wasn't that *you*?
>
> Yes. At the moment my toes are bright re
> > I would propose that the reference machine be one that one of the
> > "committers" owns, and be one whose owner is willing to *always* go
> > through the effort to resolve regression test changes and differences.
> Er ... wasn't that *you*?
Yes. At the moment my toes are bright red and sore f
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> I would propose that the reference machine be one that one of the
> "committers" owns, and be one whose owner is willing to *always* go
> through the effort to resolve regression test changes and differences.
Er ... wasn't that *you*?
> > - First one is that the regression fails on "geometry" on what appears to be
> > a difference in the 13th decimal place of the output value. See the attached
> > regression diff.
> Looks like it was not you that changed, but Thomas' reference machine.
> What platform are you on, anyway?
fwiw,
> > - First one is that the regression fails on "geometry" on what appears
to be
> > a difference in the 13th decimal place of the output value. See the
attached
> > regression diff.
>
> Looks like it was not you that changed, but Thomas' reference machine.
> What platform are you on, anyway?
>
No
"Joe Conway" <[EMAIL PROTECTED]> writes:
> I just grabbed cvs tip this afternoon and ran into two issues:
> - First one is that the regression fails on "geometry" on what appears to be
> a difference in the 13th decimal place of the output value. See the attached
> regression diff.
Looks like it
58 matches
Mail list logo
