> > I have tested today's snap shot on SunOS4.
> > For the regression test, I got 7 failures, most of them seem harmless,
> > the only concern I have is bit test though.
> > P.S. I'm going to test Linux/MIPS (Cobalt RaQ2) soon...
>
> Great! I'll update info for SunOS4 (individual problems will
> I have tested today's snap shot on SunOS4.
> For the regression test, I got 7 failures, most of them seem harmless,
> the only concern I have is bit test though.
> P.S. I'm going to test Linux/MIPS (Cobalt RaQ2) soon...
Great! I'll update info for SunOS4 (individual problems will be fixed or
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> For the regression test, I got 7 failures, most of them seem harmless,
> the only concern I have is bit test though.
Most of the diffs derive from what I recall to be a known SunOS problem,
that strtol fails to notice overflow. A value that should be re
I have tested today's snap shot on SunOS4.
% uname -a
SunOS srashd 4.1.4-JL 1 sun4m
There's a minor portability problem in
src/bin/pg_encoding/Makefile.
*** MakefileFri Mar 23 11:53:49 2001
--- Makefile.orig Wed Feb 21 18:05:21 2001
***
*** 16,28
all: submake pg_
> 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
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
(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
> 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 :)
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.
+--++
| Robert E. Bruccoleri, Ph.D. | Phone: 609 737 6383|
| President, Congenomics, In
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
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:
> "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
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 ---
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
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
[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
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
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
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
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
> 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
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).
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
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
> 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.
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,
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
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
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
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
> 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
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
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:
> 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
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
> > 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
---(
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
> 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
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
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
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
> * 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
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
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
>
* 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
> > 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
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 ...
* 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
"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
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" !=
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
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
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
"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
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
> * 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
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
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.
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
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
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
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'
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
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
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
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
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
> 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
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...")
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
> > 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
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(
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
>
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
> 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
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
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
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
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
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
> 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
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
== 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]
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
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]>
> 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
>
> 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:
> >
> > /*
> >
> 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
> 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
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
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
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,
> > 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
> * 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?
>
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
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
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
1 - 100 of 106 matches
Mail list logo
