Tom Lane <[EMAIL PROTECTED]> writes:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/doc/src/sgml'
> > cd sgml && tar -cf ../programmer.tar --exclude=Makefile
> > --exclude='*.sgml' --exclude=ref *.html -C `cd . && pwd`/graphics
> > catalogs.gi
Two more for the list (not a single regression test failing, which is a
first on Alpha!)
Tru64 4.0G Alpha cc-v6.3-129 7.1 2001-03-28
Tru64 4.0G Alpha gcc-2.95.1 7.1 2001-03-28
I updated the regression test database as well.
Adriaan
---(end of broadcast)-
Larry Rosenman <[EMAIL PROTECTED]> writes:
> gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/doc/src/sgml'
> cd sgml && tar -cf ../programmer.tar --exclude=Makefile
> --exclude='*.sgml' --exclude=ref *.html -C `cd . && pwd`/graphics
> catalogs.gif connections.gif
> tar: can't add file catalogs
Steve Nicolai <[EMAIL PROTECTED]> writes:
> I'm seeing random failures in the parallel tests run by
> "make check". Sometimes (40% or so) all tests will succeed.
> The rest of the time, I will get one or more failures.
> The specific failures are connection failures:
> ! psql: connectDBStart()
Ryan Kirkpatrick <[EMAIL PROTECTED]> writes:
> On Mon, 12 Mar 2001, Ryan Kirkpatrick wrote:
>> While testing some existing database applications on 7.1beta4 on
>> my Sparc 20 running Debian GNU/Linux 2.2, I got the following error on
>> attempting to do a vacuum of a table:
>>
>> NOTICE: FlushRe
On Wed, 21 Mar 2001, Thomas Lockhart wrote:
> OK, here is my current platform list taken from the -hackers list and
> from Vince's web page. I'm sure I've missed at least a few reports, but
> please confirm that platforms are actually running and passing
> regression tests with recent betas or th
I'm seeing random failures in the parallel tests run by
"make check". Sometimes (40% or so) all tests will succeed.
The rest of the time, I will get one or more failures.
The specific failures are connection failures:
! psql: connectDBStart() -- connect() failed: Connection refused
! Is
-BEGIN PGP SIGNED MESSAGE-
On 25 Mar 2001, at 15:02, Tom Lane wrote:
> > (rounding on the final digit) and this rather troubling output from
> > type_sanity.
>
> Most bizarre --- and definitely indicative of trouble. Would you send
> along the output of this query in that database:
>
Hi all,
Vince asked me to forward this here.
Regards and best wishes,
Justin Clift
Original Message
Subject: Re: [HACKERS] Call for platforms
Date: Sun, 25 Mar 2001 19:45:37 -0500 (EST)
From: Vince Vielhaber <[EMAIL PROTECTED]>
To: Justin Clift <[EMAIL PROTECTED]>
On Mon, 26
I'm trying to run the latest CVS code's regression tests and have a problem.
They fail at initdb with this:
Running with noclean mode on. Mistakes will not be cleaned up.
/opt/home/rmager/devel/External/pgsql/src/test/regress/./tmp_check/install//
usr/local/pgsql/bin/pg_encoding: erro
r while lo
Was just trying to recreate my docs from CVS, using the same tools
I've been using for months, and got the following:
gmake -C sgml clean
gmake[1]: Entering directory `/home/ler/pg-dev/pgsql/doc/src/sgml'
rm -f catalog
rm -f HTML.manifest *.html
rm -rf *.1 *.l man1 manl manpage.refs manpage.links
On Mon, 12 Mar 2001, Ryan Kirkpatrick wrote:
> While testing some existing database applications on 7.1beta4 on
> my Sparc 20 running Debian GNU/Linux 2.2, I got the following error on
> attempting to do a vacuum of a table:
>
> NOTICE: FlushRelationBuffers(jobs, 1399): block 953 is refer
> Following up on the recent bug report from Steve Nicolai, I spent a
> tedious hour groveling through all the warnings emitted by gcc with
> -Wcast-align. (We ought to try to reduce the number of them, but that's
> a task for another day.)
>
> I found seven places, in addition to the tuptoaster
Following up on the recent bug report from Steve Nicolai, I spent a
tedious hour groveling through all the warnings emitted by gcc with
-Wcast-align. (We ought to try to reduce the number of them, but that's
a task for another day.)
I found seven places, in addition to the tuptoaster.c error ori
Does that database have any user-created relations in it, or is it
just a virgin database? It seems that the wrong attlen is being
computed for ctid fields during bootstrap, but the regression test
output (if it was complete) implies that the value inserted for
user-created fields was OK. This d
> what's the postgresql equivalent of
>
> mysql_real_escape_string()
>
> to escape strings that are going to be passed to queries?
There doesn't seem to be a function to do this in libpq, which I find
slightly odd.
DBD::Pg has quote() function as per usual for perl's DBI, but that's
not a lo
On Fri, 23 Mar 2001, Gordon A. Runkle wrote:
> In article <[EMAIL PROTECTED]>, "The
> Hermit Hacker" <[EMAIL PROTECTED]> wrote:
>
>
> > 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, tonigh
"Mark Knox" <[EMAIL PROTECTED]> writes:
>> Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox
> Compiled and tested 7.1beta6 tonight. All the regression tests passed
> except two - the usual minor differences in geometry (rounding on the
> final digit) and this rather troubling output from type_sanit
"Gordon A. Runkle" <[EMAIL PROTECTED]> writes:
> Will upgrading from Beta6 to RC1 require dumping and restoring
> databases?
No, just compile and install. If you'd been on beta5 or earlier,
you'd need to run contrib/pg_resetxlog to update pg_control format,
but still no initdb.
Philippe Rochat writes:
> I think there is a prob with regexp, which is comparing one less
> character as it should. Below is an example. Result is that last
> character is omitted !
A '*' means "zero or more of the preceeding character". You probably want
a '+'.
>
> Ph.R.
>
> postgres=# selec
Philippe Rochat <[EMAIL PROTECTED]> writes:
> I think there is a prob with regexp, which is comparing one less
> character as it should. Below is an example. Result is that last
> character is omitted !
Possibly there is a problem with your understanding of regexp patterns
... but all those match
I think there is a prob with regexp, which is comparing one less
character as it should. Below is an example. Result is that last
character is omitted !
Ph.R.
postgres=# select * from pg_database where datname ~ 'ibd01*';
datname | datdba | encoding | datpath
-++--+
Marko Kreen writes:
> 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.
Can you check whether it matches any of the othe
In article <[EMAIL PROTECTED]>, "The
Hermit Hacker" <[EMAIL PROTECTED]> wrote:
> 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 ...
Well, d
-BEGIN PGP SIGNED MESSAGE-
On 22 Mar 2001, at 14:29, Thomas Lockhart wrote:
> Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox
Compiled and tested 7.1beta6 tonight. All the regression tests passed
except two - the usual minor differences in geometry (rounding on the
final digit) and this
The Hermit Hacker wrote:
>
> 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
> Alexander Klimov <[EMAIL PROTECTED]> writes:
>> Suddenly I obtain access to
>> ULTRIX black 4.3 1 RISC
> Uh ... what kind of processor is that? Offhand I don't see any
> indication that any of the entries in s_lock.h are supposed to work
> for Ultrix.
On closer look I notice that the putativ
Tom Lane <[EMAIL PROTECTED]> writes:
> Alexander Klimov <[EMAIL PROTECTED]> writes:
> > Suddenly I obtain access to
> > ULTRIX black 4.3 1 RISC
>
> Uh ... what kind of processor is that? Offhand I don't see any
> indication that any of the entries in s_lock.h are supposed to work
> for Ultrix.
Alexander Klimov <[EMAIL PROTECTED]> writes:
> Suddenly I obtain access to
> ULTRIX black 4.3 1 RISC
Uh ... what kind of processor is that? Offhand I don't see any
indication that any of the entries in s_lock.h are supposed to work
for Ultrix.
regards, tom lane
---
Hi all.
Suddenly I obtain access to
ULTRIX black 4.3 1 RISC
I don't shure is it supported, but I see /src/include/port/ultrix4.h file
so my guess is `yes, at least was'. I got last version from CVS and try
configure && gmake
it results in
gcc -Wall -Wmissing-prototypes -Wmissing-declarations
Roberto Mello <[EMAIL PROTECTED]> writes:
> I like the way the Oracle functions are documented, except for the
> fact that they have one huge page for all functions, which is hard on
> those on slow connections reading docs online.
> They have functions in tables grouped per functiona
On Sat, Mar 24, 2001 at 11:32:02AM -0500, Tom Lane wrote:
>
> A "page per function" approach is clearly overkill for the vast majority
> of our functions. I think that's not unrelated to the fact that no one's
> ever bothered to prepare such documentation ;-)
Agreed.
> On the other ha
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> I'm just starting to go through the sections, so right now, none of them
> have answers yet ... if ppl could help by reading through and providing
> answers so that I can provide as accurate of information as possible, it
> should give for a good in
33 matches
Mail list logo
