Giles Lean <[EMAIL PROTECTED]> writes:
> 2. I saw two different sets of output for geometry.out. These seem to
>relate to the processor level:
Okay, here are my results:
Box 1: C180 (2.0 PA8000), HPUX 10.20
Compile with gcc: all tests pass
Compile with cc: two lines of diffs in geometry (a
> Hm, I thought I had updated that before beta6. What it has now is
> The parallel regression test script (gmake check) is known to lock up
> when run under HP's default Bourne shell, at least in HPUX 10.20. This
> appears to be a shell bug, not the fault of the script. If you see that
> th
I would like to add to the release.sgml file. Seems that should be near
the end like the platform list.
> Are we ready to start freezing docs? I'll assume that the tutorial
> sections can freeze first, and that the admin sections will freeze last
> (to get the latest platform support info).
>
>
> >I'll look at this next week. If someone can confirm that
> >/usr/bin/sh works for make check on HP-UX 10.20 that would be
> >useful.
>
> It does not work. See FAQ_HPUX.
I'm confused: I don't see anything about shells or make check hanging
in doc/FAQ_HPUX. There is clear instru
Giles Lean <[EMAIL PROTECTED]> writes:
>> It does not work. See FAQ_HPUX.
> I'm confused: I don't see anything about shells or make check hanging
> in doc/FAQ_HPUX. There is clear instruction to use GNU make, which I
> am doing.
Hm, I thought I had updated that before beta6. What it has now i
Hi,
what's the postgresql equivalent of
mysql_real_escape_string()
to escape strings that are going to be passed to queries?
(http://www.mysql.com/doc/n/o/node_641.html)
Thanks
Daniel
---(end of broadcast)---
TIP 2: you can get off all lists
Giles Lean <[EMAIL PROTECTED]> writes:
>I'll look at this next week. If someone can confirm that
>/usr/bin/sh works for make check on HP-UX 10.20 that would be
>useful.
It does not work. See FAQ_HPUX.
> 2. I saw two different sets of output for geometry.out. These seem to
>rel
Hi all,
I've built 7.1beta6 on a number of different HP-UX platforms (11.00 32
bit, 11.00 64 bit, 11i 32 bit).
1. On all these platforms 'make check' hung. Since that's not
critical to whether PostgreSQL works or not I worked around it by
using a different shell:
gmake SHELL=$HOME/bin
Are we ready to start freezing docs? I'll assume that the tutorial
sections can freeze first, and that the admin sections will freeze last
(to get the latest platform support info).
Any preference on order, and does anyone have more docs changes in the
pipe? If so, we had better plan on doing the
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> I'm going to hold off on a formal announcement to -announce until tomorrow
> evening, to give the mirrors a chance to update, but if anyone would like
> to download and run through the package, make sure all looks okay, its
> available in the dev dir
Well, its been a hard, arduous journey for this one, with several delays
caused by the massive amount of changes that have gone into v7.1 ... but,
tonight I've finally wrapped up Release Candidate 1 ...
I'm going to hold off on a formal announcement to -announce until tomorrow
evening, to give t
Can I get a go/nogo decision on whether these two functions can be #if'd
out for 7.1?
Thanks.
LER
>> Original Message <<
On 3/22/01, 4:02:45 PM, Larry Rosenman <[EMAIL PROTECTED]> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
> OK, it *IS* ju
> -Original Message-
> From: Matthew
>
> > > The vacuum I tried in single user mode failed (froze on a
> > > table, for over 20 minutes) so I killed it.
> >
> > Did you destroy indices before vacuum?
> >
> Not all of them, it's a large database and I am trying to get it up
> and runni
bpalmer <[EMAIL PROTECTED]> writes:
> seconds. Most of the time is spent in this test:
> parallel group (13 tests): float4 int2 int4 text name varchar oid boolean
> char float8 int8 bit numeric
> There is a long pause between 'bit' and 'numeric'. Same with on i386. Is
> this a problem that i
> What do you mean by the whole database? I have already
> executed:
>
> reindex database cms force
> reindex table cases force
> reindex table cases force
> reindex table hits force
> reindex table history force (and a few more)
>
> How do I get it do
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> ANSI C says the same thing, although of course it only discusses int and
>> long. But the spec has always been clear that the implied type of an
>> integer constant is whatever it takes to hold it; you do not need an
>> explicit "L" suffix to
> The vacuum I tried in single user mode failed (froze on a
> table, for over 20 minutes) so I killed it.
Did you destroy indices before vacuum?
Vadim
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
> > The vacuum I tried in single user mode failed (froze on a
> > table, for over 20 minutes) so I killed it.
>
> Did you destroy indices before vacuum?
>
Not all of them, it's a large database and I am trying to get it up
and running asap.
FYI now when I try to use psql to conn
> Matthew <[EMAIL PROTECTED]> writes:
> > FYI now when I try to use psql to connect to the database I get this
> > error:
> > bash$ psql cms
> > psql: FATAL 1: cannot find attribute 1 of relation pg_trigger
>
> So the indexes on pg_attribute are hosed too. I wonder whether that was
Matthew <[EMAIL PROTECTED]> writes:
> What do you mean by the whole database? I have already executed:
> reindex database cms force
(checks manual...) That appears to be the right syntax. If you did
that in a standalone backend with the appropriate command line options
(-O and -P)
> > > The vacuum I tried in single user mode failed (froze on a
> > > table, for over 20 minutes) so I killed it.
> >
> > Did you destroy indices before vacuum?
> >
> Not all of them, it's a large database and I am trying
> to get it up and running asap.
Did you destroy *all* indices of table
Matthew <[EMAIL PROTECTED]> writes:
> FYI now when I try to use psql to connect to the database I get this
> error:
> bash$ psql cms
> psql: FATAL 1: cannot find attribute 1 of relation pg_trigger
So the indexes on pg_attribute are hosed too. I wonder whether that was
the orig
> OpenBSD 2.8 x867.1 2001-03-22, Brandon. Palmer
OBSD checks out for sparc and i386. We did need to make a change to the
resultmap file to make the regression tests clean for the sparc. I have
attached the diff.
Also, on the sparc that i'm using (sparc4/110), make check takes 1950
se
> >> I'm aware that some compilers will produce warnings about these
> >> constants, but there should not be any that fail completely, since
> >> (a) we won't be compiling this code unless we've proven that the
> >> compiler supports a 64-bit-int datatype, and
>
> > Unfortunately configure does
> Postgre 7.0.3, on RedHat Linux 6.2 stock 2.2.16 kernel. Nothing special I
> can think of, this server has been up and in use for the last 128 days
> with
> no problem. Last night while cron was performing the nightly vacuuming of
> all databases on one of our servers, I got this from cron.
>
> Matthew <[EMAIL PROTECTED]> writes:
> > [ a tale of woe ]
>
> It looks like dropping and rebuilding *all* the indexes on your history
> table would be a good move (possibly with a vacuum of the table while
> the indexes are removed). You might want to do a COPY out to try to
> save the table d
Matthew <[EMAIL PROTECTED]> writes:
> [ a tale of woe ]
It looks like dropping and rebuilding *all* the indexes on your history
table would be a good move (possibly with a vacuum of the table while
the indexes are removed). You might want to do a COPY out to try to
save the table data before the
> I have since stopped the database server and all my users are
> dead in the water at the moment. I took postgres down to single
> user mode and I'm doing a vacuum and was considering doing an
> iccpclean. Any other suggestions? dump & restore?
> Any Idea what happened?
Drop indices; vacuum; c
Postgre 7.0.3, on RedHat Linux 6.2 stock 2.2.16 kernel. Nothing special I
can think of, this server has been up and in use for the last 128 days with
no problem. Last night while cron was performing the nightly vacuuming of
all databases on one of our servers, I got this from cron.
Vacuuming cm
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> I'm aware that some compilers will produce warnings about these
>> constants, but there should not be any that fail completely, since
>> (a) we won't be compiling this code unless we've proven that the
>> compiler supports a 64-bit-int datatyp
> > Recent changes in pg_crc.c (64 bit CRC) introduced non
> portable constants of the form:
>
> > -c -o pg_crc.o pg_crc.c
> > 287 | 0x, 0x42F0E1EBA9EA3693,
> > a..
> > a - 1506-207 (W) Integer constant 0x42F
On 23 Mar 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
> Vince Vielhaber <[EMAIL PROTECTED]> writes:
>
> > On 22 Mar 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
> >
> > > [EMAIL PROTECTED] (Trond Eivind Glomsrød) writes:
> > >
> > > > Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > > >
> >
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> 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
>
On Fri, Mar 23, 2001 at 02:51:33PM +, Thomas Lockhart wrote:
>
> The ref/current_{date,time...}.sgml files are there because (a)
> functions should be documented, and (b) someone documented them. But we
> never documented enough functions to justify setting up an entire
> section of a manual
> > I have a plan to translate 7.1 docs into Japanases and I looked around
> > current docs. I noticed that contacts.sgml and ref/current*.sgml are
> > not used anywhere in the result html nor in man pages.
> > Does anybody know the reason? Or am I missing something?
>
> I put in contacts.sgml a
> I have a plan to translate 7.1 docs into Japanases and I looked around
> current docs. I noticed that contacts.sgml and ref/current*.sgml are
> not used anywhere in the result html nor in man pages.
> Does anybody know the reason? Or am I missing something?
I put in contacts.sgml a *long* time
On Thu, Mar 22, 2001 at 11:33:16AM +1030, Steven Vajdic wrote:
> 2. I am thinking about Debian (my preferred option - good/easy for
> "automatic" WEB upgrades) or
I surely second that. :-)
My experience is that the Debian upgrade mechanism is much better than that
of the other dists. But you wil
I have a plan to translate 7.1 docs into Japanases and I looked around
current docs. I noticed that contacts.sgml and ref/current*.sgml are
not used anywhere in the result html nor in man pages.
Does anybody know the reason? Or am I missing something?
--
Tatsuo Ishii
---(e
On Thu, Mar 22, 2001 at 07:58:04PM +, Patrick Welche wrote:
> 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
> 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
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> >> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > ! FATAL 2: ZeroFill(logfile 0 seg 1) failed: No such file or directory
> > ! pqReadData() -- backend closed the channel unexpectedly.
> >>
> >> Is it possible you ran out of disk space?
>
> > Probably n
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> The bit test diffs seem to indicate that bit_cmp is messed up. That
>> depends on memcmp. I seem to recall something about memcmp not being
>> 8-bit-clean on SunOS ... does that ring a bell with anyone?
> Good point. From the man page of memcmp(3) on
42 matches
Mail list logo
