> This is a portability bug, no question. But I'd expect it to fail
> like that on all Alpha-based platforms. Adriaan, when you say it
> works on Linux, are you talking about Linux/Alpha or some other
> hardware?
No, PC Linux. I run a database on my laptop as well.
Adriaan
---
Results of 'make check':
NetBSD-1.5/i386 one spurious floating point test failure
(mail sent to postgresql-bugs with details)
NetBSD_1.5/alphaall tests passed
NetBSD-1.4.2/i386 four tests fail
timestamp... FAILED
* Bruce Momjian <[EMAIL PROTECTED]> [010321 23:08]:
> Works fine here.
on a GCC platform, it does. I suspect this is a portability issue.
LER
>
>
> > Since I am playing with StarOffice, I figured I'd try --with-odbc,
> > current sources, except for the big Bruce commit I just saw :-)
> >
>
OK: Linux 2.4.2 i686 / gcc 2.95.2 / Debian testing/unstable
no problems.
OK?: NetBSD 1.5 i586 / egcs 2.91.66 / (netbsd-1-5 from Jan)
netbsd FAILED the geometry test, diff attached, dunno if its
critical or not.
--
marko
*** ./expected/geometry-positive-zeros.out Wed Mar 21 15:07:12
> NetBSD-1.5/i386 one spurious floating point test failure
> (mail sent to postgresql-bugs with details)
> NetBSD_1.5/alphaall tests passed
> NetBSD-1.4.2/i386 four tests fail
Thanks! I'm not too worried about 1.4.2, but be sure to let us know what
the problem was; i
Bruce Momjian wrote:
> I have talked to Jan over the phone, and he has convinced me that UDP is
> the proper way to communicate stats to the collector, rather than my
> shared memory idea.
>
> The advantages of his UDP approach is that the collector can sleep on
> the UDP socket rather than having
Here is the current scorecard. We have a couple of new platforms
reported (yeaaa!):
NetBSD 2.8 alpha 7.1 2001-03-22, Giles Lean
OpenBSD 2.8 x867.1 2001-03-22, B. Palmer (first name?)
Any more OpenBSD architectures out there running PostgreSQL? Here are
the remaining (unreported, or unnoted
On Thu, 22 Mar 2001, Thomas Lockhart wrote:
> Solaris x867.0 2000-04-12, Marc Fournier
>
> scrappy, do you still have this machine?
Doing tests on Solaris x86/7 right now, will report as soon as they are
done ...
> Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut
>
> I'll bet th
> * Bruce Momjian <[EMAIL PROTECTED]> [010321 21:14] wrote:
> > > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > > > and most times, those have to be merged into the source tree due to
> > > > extensive changes anyway ... maybe we should just get rid of the use of
> > > > pgindent altogether?
>
> > FreeBSD 4.2 x867.1 2001-03-19, Vince Vielhaber
> FreeBSD 4.3-BETA is good to go also ...
Yeah, I'm not sure how to list that, or whether to bother. It is beta,
4.2 works fine (and nothing had to change for 4.3, right?) so maybe we
just list it when 4.3 goes stable? Or is 4.3 sufficiently
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> cvs annotate is a really, really handy tool, unfortunetly these
> indent runs remove this very useful tool as well as do a major job
> of obfuscating the code changes.
I think this is a good reason for *not* applying pgindent on an
incremental basis,
Hi,
On Thu, 22 Mar 2001, Thomas Lockhart wrote:
> > - fields defined as TIMESTAMP DEFAULT CURRENT_TIMESTAMP sometimes generate
> > invalid format of the date, for instance:
> > 2001-02-10 13:11:60.00+01
>
> You are running the Mandrake RPMs? Or have otherwise compiled using the
> -ffast-math
How much 'diviation' are we allowing for?
Solaris x86/7 results, for example, in geometry.out, show a difference of:
1.53102359078377e-11,3 (expected)
1.53102359017709e-11,3 (results)
or
3,-3.06204718156754e-11 (expected)
3,-3.06204718035418e-11 (results)
acceptable diviation?
On Thu, 22 Ma
> It seems that you guys are dead set on using this pgindent tool,
> this is cool, we'd probably use some indentation tool on the FreeBSD
> sources if there was one that met our code style(9) guidelines.
I would liken running pgindent to having a nice looking store or
website. No one is going to
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > cvs annotate is a really, really handy tool, unfortunetly these
> > indent runs remove this very useful tool as well as do a major job
> > of obfuscating the code changes.
>
> I think this is a good reason for *not* applying pgindent on an
> incr
> Solaris x86/7 results, for example, in geometry.out, show a difference of:
> 3,-3.06204718156754e-11 (expected)
> 3,-3.06204718035418e-11 (results)
> acceptable diviation?
That sort of deviation is well within bounds, particularly for geometry
tests which might have some transcendental math inv
4.3 is in RELEASE CANDIDATE right now. By the time we release, it should
be -RELEASE or -STABLE.
I'd include it as just 4.3.
It will be the -RELEASE at the time we are.
LER
>> Original Message <<
On 3/22/01, 8:50:26 AM, Thomas Lockhart <[EMAIL PROTECTED]>
On Thu, 22 Mar 2001, Thomas Lockhart wrote:
> > Solaris x86/7 results, for example, in geometry.out, show a difference of:
> > 3,-3.06204718156754e-11 (expected)
> > 3,-3.06204718035418e-11 (results)
> > acceptable diviation?
>
> That sort of deviation is well within bounds, particularly for geom
== shutting down postmaster ==
==
All 76 tests passed.
==
rm regress.o
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED]
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> cvs annotate is a really, really handy tool, unfortunetly these
> indent runs remove this very useful tool as well as do a major job
> of obfuscating the code changes.
>>
>> I think this is a good reason f
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > cvs annotate is a really, really handy tool, unfortunetly these
> > indent runs remove this very useful tool as well as do a major job
> > of obfuscating the code changes.
> >>
> >> I think this is a
On Thu, 22 Mar 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > Nope, still working through some things ... the select_implicit test
> > failed completely:
>
> > dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more
>results/select_implicit.out
> > psql:
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> Nope, still working through some things ... the select_implicit test
> failed completely:
> dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more
>results/select_implicit.out
> psql: connectDBStart() -- connect() failed: Connection
> > OpenBSD 2.8 x867.1 2001-03-22, B. Palmer (first name?)
> Though it does work, like FBSD, there are some changes that need to be
> made to the system. Need max proc / files changes and a kernel recompile
> with SEMMNI and SEMMNS changes. Anywhere special to note this?
So more-or-less t
I'm currently concerned about these recent reports:
* Joel Burton's report of disappearing files, 3/20. This is real scary,
but no one else has reported anything like it.
* Tatsuo's weird failure in XLogFileInit ("ZeroFill: no such file or
directory"). I'm hoping this can be explained away, bu
Larry Rosenman writes:
> cc -G -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o columninfo.o
>connection.o convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o
>pgtypes.o psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o tuple.o
>tuplelist.o dlg_spec
Bruce Momjian writes:
> > >> Are there any severely mis-indented files?
> >
> > There are some new contrib modules that are nowhere close to our
> > indent conventions; also a good deal of foreign-key-related stuff
> > in the parser that needs to be cleaned up. So we should run it.
> >
> > I've
On Thu, 22 Mar 2001, Thomas Lockhart wrote:
> > > OpenBSD 2.8 x867.1 2001-03-22, B. Palmer (first name?)
> > Though it does work, like FBSD, there are some changes that need to be
> > made to the system. Need max proc / files changes and a kernel recompile
> > with SEMMNI and SEMMNS change
> I'm currently concerned about these recent reports:
>
> * Joel Burton's report of disappearing files, 3/20. This is real scary,
> but no one else has reported anything like it.
>
> * Tatsuo's weird failure in XLogFileInit ("ZeroFill: no such file or
> directory"). I'm hoping this can be expl
Can't we do something with atexit or other PORTABLE end stuff?
I'll look at it for 7.2.
LER
>> Original Message <<
On 3/22/01, 10:16:03 AM, Peter Eisentraut <[EMAIL PROTECTED]> wrote regarding
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.:
> Larry Rosenman writ
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> the second time
> failed *totally* different tests then the first run:
> dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> grep
> FAILED regression.out
> opr_sanity ... FAILED
> join ... FAILED
>
The Hermit Hacker writes:
> > Is Solaris-x86 ready to go then?
>
> Nope, still working through some things ... the select_implicit test
> failed completely:
>
> dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more
>results/select_implicit.out
> psql: connectDBStart() -- connect(
> > Hey, I am open to whatever people want to do. Just remember that we
> > accumulate lots of patches/development during the slow time before
> > development, and those patches become harder to apply. Peter E has some
> > already.
>
> This argument seems irrelevant when given the choice of bef
Thomas Lockhart writes:
> ?? I think we agree. It happens to be the case that slightly incorrect
> results are wrong results, and that full IEEE math conformance gives
> exactly correct results. For the case of date/time, the "slightly wrong"
> results round up to 60.0 seconds for times on an eve
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think early beta is the time to
> do this next time. That has the fewest patches crossing over time.
That would work too, particularly if you give people a few days' notice.
("Get your patches in now, or expect to have to reformat...")
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think early beta is the time to
> > do this next time. That has the fewest patches crossing over time.
>
> That would work too, particularly if you give people a few days' notice.
> ("Get your patches in now, or expect to have to reformat...")
Y
On Thu, 22 Mar 2001, Thomas Lockhart wrote:
> OpenBSD 2.8 x867.1 2001-03-22, B. Palmer (first name?)
Though it does work, like FBSD, there are some changes that need to be
made to the system. Need max proc / files changes and a kernel recompile
with SEMMNI and SEMMNS changes. Anywhere sp
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Larry Rosenman writes:
>> Why do WE define _fini?
> Because we need to 'fini' something, I suspect.
See src/interfaces/odbc/psqlodbc.c line 126. It doesn't look to me like
the _fini() does anything useful; could we take it out?
We do not actually
The Hermit Hacker writes:
> How much 'diviation' are we allowing for?
>
> Solaris x86/7 results, for example, in geometry.out, show a difference of:
>
> 1.53102359078377e-11,3 (expected)
> 1.53102359017709e-11,3 (results)
>
> or
>
> 3,-3.06204718156754e-11 (expected)
> 3,-3.06204718035418e-11 (re
Thomas Lockhart writes:
> Here is the current scorecard. We have a couple of new platforms
> reported (yeaaa!):
> QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos
This one is getting a "no good", as of latest reports. There are some
issues to be worked out in the dreaded spin lock area, w
Thomas Lockhart writes:
> > > OpenBSD 2.8 x867.1 2001-03-22, B. Palmer (first name?)
> > Though it does work, like FBSD, there are some changes that need to be
> > made to the system. Need max proc / files changes and a kernel recompile
> > with SEMMNI and SEMMNS changes. Anywhere special
Tom Lane writes:
> > #if
> > #define L64 L
> > #else
> > #define L64 LL
> > #endif
>
> > const uint64 crc_table[256] = {
> > 0x##L64, 0x42F0E1EBA9EA3693##L64,
> > 0x85E1C3D753D46D26##L64, 0xC711223CFA3E5BB5##L64,
>
> Hmm ... how portable is that likely to be?
If the 'L'
Larry Rosenman writes:
> Can't we do something with atexit or other PORTABLE end stuff?
It's supposed to work transparently for the library user. At least the
_fini can probably be hooked in atexit, but the _init would probably have
to be handled some other way. Maybe some
if (!already_inited
Is it possible to fix this before RC1?
bray=# \d price
Table "price"
Attribute | Type | Modifier
-+---+--
product | character varying(10) | not null
cost| numeric(12,2) | not null
home| nu
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> const uint64 crc_table[256] = {
> 0x##L64, 0x42F0E1EBA9EA3693##L64,
> 0x85E1C3D753D46D26##L64, 0xC711223CFA3E5BB5##L64,
>>
>> Hmm ... how portable is that likely to be?
> If the 'L' or 'LL' suffix is portable (probably), and token pa
Looks like initdb is just a tad too strict when checking to make sure
the data directory is empty. Yesterday I created a new data directory
as it's own filesystem (linux ext2), it includes a lost+found directory.
To initdb this means that the directory is no longer empty and it refuses
to run.
Tom Lane writes:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > If it doesn't work, and will not be made to work, then let's remove it
> > from the tree.
>
> I tend to agree with Peter's slightly less drastic proposal: remove it
> >from the installed fileset and disable its man page, without n
> * Joel Burton's report of disappearing files, 3/20. This is
> real scary, but no one else has reported anything like it.
Can please you remind that report?
Vadim
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregi
In a very quick look I just made, I tend to agree with Tom, that the
whole non-gcc, non-windows stuff should go.
LER
>> Original Message <<
On 3/22/01, 10:20:11 AM, Tom Lane <[EMAIL PROTECTED]> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
> P
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> * Joel Burton's report of disappearing files, 3/20. This is
>> real scary, but no one else has reported anything like it.
> Can please you remind that report?
It's the "pg_inherits: not found, but visible" thread in pghackers
on 3/20 and 3/21. B
On Thu, Mar 22, 2001 at 05:25:01PM +0100, Peter Eisentraut wrote:
> Marko Kreen writes:
> >
> > OK?: NetBSD 1.5 i586 / egcs 2.91.66 / (netbsd-1-5 from Jan)
> >
> > netbsd FAILED the geometry test, diff attached, dunno if its
> > critical or not.
>
> Can you check whether it matches any of the oth
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> It's supposed to work transparently for the library user. At least the
> _fini can probably be hooked in atexit, but the _init would probably have
> to be handled some other way.
The _fini does nothing, and I already made a hack to cover lack of the
Steve Stock writes:
> Looks like initdb is just a tad too strict when checking to make sure
> the data directory is empty. Yesterday I created a new data directory
> as it's own filesystem (linux ext2), it includes a lost+found directory.
It is never a good idea to let initdb loose on a directo
Steve Stock <[EMAIL PROTECTED]> writes:
> --- src/bin/initdb/initdb.sh2001/03/13 21:37:15 1.122
> +++ src/bin/initdb/initdb.sh2001/03/22 15:45:46
> @@ -402,7 +402,7 @@
> # find out if directory is empty
> pgdata_contents=`ls -A "$PGDATA" 2>/dev/null`
> -if [ x"$pgdata_contents" !=
"Oliver Elphick" <[EMAIL PROTECTED]> writes:
> Is it possible to fix this before RC1?
If it were an easily fixed thing, it would have been fixed long ago.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked o
* Bruce Momjian <[EMAIL PROTECTED]> [010322 06:49] wrote:
> > * Bruce Momjian <[EMAIL PROTECTED]> [010321 21:14] wrote:
> > > > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > > > > and most times, those have to be merged into the source tree due to
> > > > > extensive changes anyway ... maybe w
On Thu, 22 Mar 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > the second time
> > failed *totally* different tests then the first run:
>
> > dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> grep
> > FAILED regression.out
> > opr_sanity ...
> > You don't notice the value of pgindent until you have some code that
> > hasn't been run through it. For example, ODBC was not run through until
> > this release, and I had a terrible time trying to understand the code
> > because it didn't _look_ like the rest of the code. Now that pgindent
* Bruce Momjian <[EMAIL PROTECTED]> [010322 07:12] wrote:
> > It seems that you guys are dead set on using this pgindent tool,
> > this is cool, we'd probably use some indentation tool on the FreeBSD
> > sources if there was one that met our code style(9) guidelines.
>
> I would liken running pgi
The Hermit Hacker <[EMAIL PROTECTED]> writes:
>> These are parallel tests right? What's the failure diffs?
> same as last time:
> dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more
> results/opr_sanity.out
> psql: connectDBStart() -- connect() failed: Connection refused
>
Just a data point on the geometry test under NetBSD/i386 issue:
/etc/ld.so.conf by default now contains:
libm.so.0 machdep.fpu_present 1:libm387.so.0,libm.so.0
which means that if the sysctl machdep.fpu_present returns 1, load the
shared library libm387 to make use of the fpu.
If you
> * Bruce Momjian <[EMAIL PROTECTED]> [010322 07:12] wrote:
> > > It seems that you guys are dead set on using this pgindent tool,
> > > this is cool, we'd probably use some indentation tool on the FreeBSD
> > > sources if there was one that met our code style(9) guidelines.
> >
> > I would liken
Adriaan Joubert <[EMAIL PROTECTED]> writes:
> insert into lint values ('9223372036854775807'::int8);
> works, but
> insert into lint values (9223372036854775807::int8);
> doesn't.
Fixed, and checked on Debian Alpha.
regards, tom lane
---(end of
Does this mean it's eligible to be fixed for 7.1?
LER
>> Original Message <<
On 3/22/01, 11:05:29 AM, Tom Lane <[EMAIL PROTECTED]> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > It's supposed to
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Does this mean it's eligible to be fixed for 7.1?
We can talk about it anyway. Does removing the _fini alone make it work
for you, or do we have to remove _init too?
regards, tom lane
---(end of broad
>
> On Thu, Mar 22, 2001 at 01:25:07AM -0500, Bruce Momjian wrote:
> > I have finished pgindent. We also had many old comments of the format:
> >
> > /* --
> > * comment
> > * --
> > */
> >
> > These are now the more concise:
> >
> > /*
> >
> PS: AFAIK geometry-positive-zeros-bsd works for all NetBSD platforms - the
> above difference is only for i386 + fpu.
It doesn't on NetBSD-1.5/alpha -- there geometry-positive-zeros is
correct.
Regards,
Giles
---(end of broadcast)---
TIP 6: Ha
On Thu, Mar 22, 2001 at 06:16:03PM +0100, Peter Eisentraut wrote:
> It is never a good idea to let initdb loose on a directory that might
> possibly have some other purpose, including that of being the root
> directory of an ext2 partition. Initdb or the database system can do
> anything they wan
> > NetBSD 2.8 alpha 7.1 2001-03-22, Giles Lean
> Correction: NetBSD-1.5/alpha.
Right. That was a typo in transcribing my online copy of the sgml docs
to the email. I was hoping no one caught it, and didn't bother sending a
correction ;)
- Thomas
---(
need to kill the _init too. Then we get other symbol issues, I think due
to -Wl,z,text, but I'm not sure.
ar crs libpsqlodbc.a `lorder info.o bind.o columninfo.o connection.o
convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o
psqlodbc.o qresult.o results.o socket.o par
Larry Rosenman writes:
> need to kill the _init too. Then we get other symbol issues, I think due
> to -Wl,z,text, but I'm not sure.
These look to be due to the -Bsymbolic. Note they're only warnings, but
you could really only tell by trying out the driver. I have a slight
suspicion that -z t
On Thu, Mar 22, 2001 at 12:49:39PM -0500, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> >> These are parallel tests right? What's the failure diffs?
>
> > same as last time:
>
> > dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more
> > results/opr_sanity.ou
Larry Rosenman writes:
> using the following link, with the _init/_fini killed, works:
>
> cc -G *.o -L /usr/local/pgsql/lib -lpq -R/usr/local/pgsql/lib -lsocket -o
> libpsqlodbc.so.0.26
The libpq should definitely not be there, but if additional libraries such
as -lsocket make you happy then lo
> NetBSD 2.8 alpha 7.1 2001-03-22, Giles Lean
Correction: NetBSD-1.5/alpha.
Ciao,
Giles
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
FYI.
- Forwarded message from Jordan Hubbard <[EMAIL PROTECTED]> -
Sender: [EMAIL PROTECTED]
From: Jordan Hubbard <[EMAIL PROTECTED]>
Subject: Revised schedule for 4.3-RELEASE
Date: Thu, 22 Mar 2001 12:04:09 -0800
Message-Id: <[EMAIL PROTECTED]>
X-Mailer: Mew version 1.94.1 on Emacs
On Thu, Mar 22, 2001 at 10:27:44PM +0200, Marko Kreen wrote:
> On Thu, Mar 22, 2001 at 07:58:04PM +, Patrick Welche wrote:
> >
> > AFAIK geometry-positive-zeros works for all NetBSD platforms - the
> > above difference is only for i386 + fpu.
>
> Seems that following patch is needed. Now It
using the following link, with the _init/_fini killed, works:
cc -G *.o -L /usr/local/pgsql/lib -lpq -R/usr/local/pgsql/lib -lsocket -o
libpsqlodbc.so.0.26
SO, Peter, how do we fix the generated make file?
> Original Message <<
On 3/22/01, 12:23:57 PM, Tom L
Peter,
I'm not a GNU MAKE person, can you help here?
LER
> Original Message <<
On 3/22/01, 12:49:10 PM, Tom Lane <[EMAIL PROTECTED]> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > need to kill
and before you ask, the _init and _fini NEED to go away.
LER
>> Original Message <<
On 3/22/01, 1:00:08 PM, Larry Rosenman <[EMAIL PROTECTED]> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
> using the following link, with the _init/_fini killed,
> Well, you're going to have to ask a numerical analyst about this. If you
> take that stance then -ffast-math is always wrong, no matter what the
> combination of other switches. The "wrong" results might be harder to
> reproduce without any optimization going on, but they could still happen.
Larry Rosenman <[EMAIL PROTECTED]> writes:
> need to kill the _init too. Then we get other symbol issues, I think due
> to -Wl,z,text, but I'm not sure.
Um. This suggests that the real problem is a completely wrong approach
to linking the shared lib. On this evidence I'm not going to touch t
On Fri, Mar 23, 2001 at 06:25:50AM +1100, Giles Lean wrote:
>
> > PS: AFAIK geometry-positive-zeros-bsd works for all NetBSD platforms - the
> > above difference is only for i386 + fpu.
>
> It doesn't on NetBSD-1.5/alpha -- there geometry-positive-zeros is
> correct.
Sorry, that should have rea
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> If a platform you are running on is not listed, make sure it gets
> included!
Red Hat Linux, Wolverine Beta (and some updates) - glibc 2.2.2,
2.4.2ish kernel (read: lots of fixes), gcc 2.96RH: All 76 tests passed
with 7.1beta6 (parallel_schedule).
> Seems that following patch is needed. Now It Works For Me (tm).
> Giles, does the regress test now succed for you?
Yes, but I don't like that it is 1.5 specific. I expect that later
NetBSD/i386 releases will also have the "new" floating point behaviour
by default, subject to /etc/ld.so.conf
My question is WHY are we using -Bsymbolic and/or -z text anyway?
These options don't appear to buy us anything but grief on SVR[45] ELF
systems..
The -lpq is NOT needed, that was my f*** up.
LER
>> Original Message <<
On 3/22/01, 2:50:53 PM, Peter Eisentraut
Larry Rosenman <[EMAIL PROTECTED]> writes:
> My question is WHY are we using -Bsymbolic and/or -z text anyway?
> These options don't appear to buy us anything but grief on SVR[45] ELF
> systems..
I have no idea what -z text means to your linker, but if it has a
-Bsymbolic option then it's a good
OK, will do. For the record:
-z text
In dynamic mode only, force a fatal error if any relocations
against non-writable, allocatable sections remain. This is the
default for IA-64 objects.
I don't have a good way to test it yet, as the only ODBC client I have is
S
OK, it *IS* just a WARNING that the symbols are undefined.
SO, can we get the _fini/_init stuff commented/taken out for 7.1?
LER
>> Original Message <<
On 3/22/01, 3:38:59 PM, Tom Lane <[EMAIL PROTECTED]> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No G
[EMAIL PROTECTED] (Trond Eivind Glomsrød) writes:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
>
> > If a platform you are running on is not listed, make sure it gets
> > included!
>
> Red Hat Linux, Wolverine Beta (and some updates) - glibc 2.2.2,
> 2.4.2ish kernel (read: lots of fixes), gcc
On Thu, 22 Mar 2001, Patrick Welche wrote:
> On Thu, Mar 22, 2001 at 12:49:39PM -0500, Tom Lane wrote:
> > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > >> These are parallel tests right? What's the failure diffs?
> >
> > > same as last time:
> >
> > > dragon:/home/centre/marc/src/postgresql
Bruce Momjian wrote:
>
> You don't notice the value of pgindent until you have some code that
> hasn't been run through it. For example, ODBC was not run through until
> this release, and I had a terrible time trying to understand the code
> because it didn't _look_ like the rest of the code. No
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Please tell me how to prevent pgindent from changing
> comments.
Put dashes at the start and end of the comment block, eg
/*--
* comment here
*--
*/
I'm not sure exactly how many dashes are needed ---
On Thu, 22 Mar 2001, Tom Lane wrote:
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> >> * Joel Burton's report of disappearing files, 3/20. This is
> >> real scary, but no one else has reported anything like it.
>
> > Can please you remind that report?
>
> It's the "pg_inherits: not found, b
Joel Burton <[EMAIL PROTECTED]> writes:
> I rebooted my machine, and it didn't happen again that night. Yesterday,
> my staff reinstalled Pg straight from the CVS but without (!) tarring up
> the old Pg install, so I'm afraid I don't have any logs. I run Pg w/debug
> switches on my development mac
On Thu, 22 Mar 2001, Tom Lane wrote:
> Joel Burton <[EMAIL PROTECTED]> writes:
> > I rebooted my machine, and it didn't happen again that night. Yesterday,
> > my staff reinstalled Pg straight from the CVS but without (!) tarring up
> > the old Pg install, so I'm afraid I don't have any logs. I r
I've successfully tested release 7.1beta4 on Irix 6.5.11. I'll run another
test on the most recent beta or RC next week.
+--++
| Robert E. Bruccoleri, Ph.D. | Phone: 609 737 6383|
| President, Congenomics, In
On 22 Mar 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
> [EMAIL PROTECTED] (Trond Eivind Glomsrød) writes:
>
> > Thomas Lockhart <[EMAIL PROTECTED]> writes:
> >
> > > If a platform you are running on is not listed, make sure it gets
> > > included!
> >
> > Red Hat Linux, Wolverine Beta (and so
> I've successfully tested release 7.1beta4 on Irix 6.5.11. I'll run another
> test on the most recent beta or RC next week.
Great Robert! I'll mark that as tested (if it works for you on beta4, it
will work on RC1). Looking forward to confirmation about RC1 when it
appears :)
(moved to -hackers, since I don't have posting privileges on -general)
> I've suggested before that timestamp output should round the timestamp
> value to two fractional digits *before* breaking it down into year/
> month/etc. Seems like this is a perfect example of the necessity
> for that. Th
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> I've suggested before that timestamp output should round the timestamp
>> value to two fractional digits *before* breaking it down into year/
>> month/etc. Seems like this is a perfect example of the necessity
>> for that. Thomas, what say you?
> W
1 - 100 of 106 matches
Mail list logo
