On Thu, Dec 15, 2005 at 01:16:09PM -0500, Robert Treat wrote:
> > Well, you could make the argument that switching OSes is a lot less
> > involved than switching PostgreSQL versions, especially since a
> > dump/reload isn't required...
> >
>
> How exactly do you switch the OS your database is runn
Robert Treat <[EMAIL PROTECTED]> writes:
> The one thing I am wondering is would people accept older OS's into the
> buildfarm? I think there are still a lot of servers running red hat 7.3,
> that might be an example of an old OS that we could put into the buildfarm to
> test for the 7.3.x or 7.
Robert Treat wrote:
The one thing I am wondering is would people accept older OS's into the
buildfarm? I think there are still a lot of servers running red hat 7.3,
that might be an example of an old OS that we could put into the buildfarm to
test for the 7.3.x or 7.4.x series.
"peop
On Thursday 15 December 2005 12:02, Jim C. Nasby wrote:
> On Thu, Dec 15, 2005 at 12:50:44AM -0500, Tom Lane wrote:
> > Mark Kirkwood <[EMAIL PROTECTED]> writes:
> > > I don't know if this is yet another one, but happened to rebuild 7.3.12
> > > on a FreeBSD 6.0 box today and I notice that it fails
On Thu, Dec 15, 2005 at 12:50:44AM -0500, Tom Lane wrote:
> Mark Kirkwood <[EMAIL PROTECTED]> writes:
> > I don't know if this is yet another one, but happened to rebuild 7.3.12
> > on a FreeBSD 6.0 box today and I notice that it fails float8 regression
> > test (geometry does too but that is mar
Mark Kirkwood wrote:
Tom Lane wrote:
Mark Kirkwood <[EMAIL PROTECTED]> writes:
I don't know if this is yet another one, but happened to rebuild
7.3.12 on a FreeBSD 6.0 box today and I notice that it fails float8
regression test (geometry does too but that is marked as ignorable).
7.3 is
Tom Lane wrote:
Mark Kirkwood <[EMAIL PROTECTED]> writes:
I don't know if this is yet another one, but happened to rebuild 7.3.12
on a FreeBSD 6.0 box today and I notice that it fails float8 regression
test (geometry does too but that is marked as ignorable).
7.3 is too old to know that fre
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> I don't know if this is yet another one, but happened to rebuild 7.3.12
> on a FreeBSD 6.0 box today and I notice that it fails float8 regression
> test (geometry does too but that is marked as ignorable).
7.3 is too old to know that freebsd beyond 4.x
Jim C. Nasby wrote:
On Mon, Dec 12, 2005 at 10:39:47PM -0500, Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
I think I'd just delete lines 464-470 in
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-auth.c?annotate=1.71
I confirmed that this is the patc
On Tue, Dec 13, 2005 at 02:03:13AM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > The error talks about SEMMNI and SEMMNS, but both look ok...
>
> > kern.ipc.semmns: 100
>
> That's not enough to run two postmasters ...
Odd that it works for other branches...
That's a bo
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> The error talks about SEMMNI and SEMMNS, but both look ok...
> kern.ipc.semmns: 100
That's not enough to run two postmasters ...
regards, tom lane
---(end of broadcast)---
TIP 5:
On Mon, Dec 12, 2005 at 10:39:47PM -0500, Tom Lane wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> > I think I'd just delete lines 464-470 in
> > http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-auth.c?annotate=1.71
>
> I confirmed that this is the patch appearing i
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> I think I'd just delete lines 464-470 in
> http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-auth.c?annotate=1.71
I confirmed that this is the patch appearing in 7.4 (fe-auth.c rev
1.84), so went ahead and applied it to 7.3.
Tom Lane said:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>> I don't care that much if 7.3 fails to build on fbsd 6. The flipside
>> is that the fix for this particular problem appears to be very simple
>> and very low risk, unless I'm going blind.
>
> Possibly --- if you've gone to the trouble
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> I don't care that much if 7.3 fails to build on fbsd 6. The flipside is that
> the fix for this particular problem appears to be very simple and very low
> risk, unless I'm going blind.
Possibly --- if you've gone to the trouble of identifying the rel
Tom Lane said:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>> Platypus (http://lnk.nu/pgbuildfarm.org/6yt.pl) started failing about
>> 12 days ago with the following:
>> fe-auth.c: In function `pg_local_sendauth':
>> fe-auth.c:466: error: conflicting types for 'cmsgmem'
>> fe-auth.c:459: error: pr
On Mon, Dec 12, 2005 at 06:44:23PM -0500, Tom Lane wrote:
> The PG 7.3 branch is definitely showing its age. I'm not sure how
> interesting it is to keep updating it for newer platforms; is anyone
> very likely to run 7.3 on a new machine, rather than some later PG?
Probably no one... I'll just g
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Platypus (http://lnk.nu/pgbuildfarm.org/6yt.pl) started failing about 12
> days ago with the following:
> fe-auth.c: In function `pg_local_sendauth':
> fe-auth.c:466: error: conflicting types for 'cmsgmem'
> fe-auth.c:459: error: previous declaration of
Platypus (http://lnk.nu/pgbuildfarm.org/6yt.pl) started failing about 12
days ago with the following:
ccache gcc -O3 -pipe -pipe -fno-strict-aliasing -g -Wall -Wmissing-prototypes
-Wmissing-declarations -fpic -DPIC -I. -I../../../src/include
-I/usr/local/include -DFRONTEND
-DSYSCONFDIR='"/home/b
Michael Fuhr <[EMAIL PROTECTED]> writes:
> psql segfaults a couple of times during the tests; here's a stack trace:
> #0 0xff3655e8 in DLRemHead (l=0x0) at dllist.c:170
> #1 0xff35d0c0 in PQnotifies (conn=0x4d970) at fe-exec.c:1560
> #2 0x00019334 in SendQuery (query=0x4d970 "") at common.c:501
My Solaris 9 box has the same regression failures for copy2, domain,
and alter_table in REL7_3_STABLE that caribou and stoat are showing
(geometry fails on those boxes as well, but passes on mine).
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=caribou&dt=2005-07-14%2006:42:19
http://www.pgbuil
On Mon, 10 Nov 2003, Gaetano Mendola wrote:
> Marc G. Fournier wrote:
>
> > 'k, this doesn't look right, but it could be that I'm overlooking
> > something ...
> >
> > The function I created:
> >
> > CREATE FUNCTION month_trunc (timestamp without time zone) RETURNS timestamp
> > without time zo
Marc G. Fournier wrote:
'k, this doesn't look right, but it could be that I'm overlooking
something ...
The function I created:
CREATE FUNCTION month_trunc (timestamp without time zone) RETURNS timestamp without
time zone
AS 'SELECT date_trunc(''month'', $1 )'
LANGUAGE sql IMMUTABLE;
The q
Marc G. Fournier wrote:
'k, this doesn't look right, but it could be that I'm overlooking
something ...
The function I created:
CREATE FUNCTION month_trunc (timestamp without time zone) RETURNS timestamp without
time zone
AS 'SELECT date_trunc(''month'', $1 )'
LANGUAGE sql IMMUTABLE;
The
'k, this doesn't look right, but it could be that I'm overlooking
something ...
The function I created:
CREATE FUNCTION month_trunc (timestamp without time zone) RETURNS timestamp without
time zone
AS 'SELECT date_trunc(''month'', $1 )'
LANGUAGE sql IMMUTABLE;
The query that fails:
a
> We clearly need to have a 7.3.2, but I was thinking late January would
> be about the right time frame. Bugs are still trickling in (eg, the
> plpgsql one Neil just identified), and so far we've not seen anything
> that would make me feel we need an immediate release ...
I'm biased, but I think
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are we near needing 7.3.2?
We clearly need to have a 7.3.2, but I was thinking late January would
be about the right time frame. Bugs are still trickling in (eg, the
plpgsql one Neil just identified), and so far we've not seen anything
that would make m
Are we near needing 7.3.2? The contraint dump patch is post-7.3.1 too,
and Tom applied a big fix recently to 7.3.X.
---
Laurette Cisneros wrote:
> That did the trick...fixed pg_dump!
>
> And, pg_restore works on it too!
That did the trick...fixed pg_dump!
And, pg_restore works on it too!
Yay, I can go home now.
Thanks very much for your help!
On Fri, 10 Jan 2003, Tom Lane wrote:
> Laurette Cisneros <[EMAIL PROTECTED]> writes:
> > This does not:
> > pg_dump -h myhost -p 5432 -Fc -f mydb.cpgdmp mydb
> > Segmen
Thanks.
I've nulled all the "comment on view"s but still get it...
On Fri, 10 Jan 2003, Tom Lane wrote:
> Laurette Cisneros <[EMAIL PROTECTED]> writes:
> > This does not:
> > pg_dump -h myhost -p 5432 -Fc -f mydb.cpgdmp mydb
> > Segmentation fault (core dumped)
>
> If you have any comments on
Laurette Cisneros <[EMAIL PROTECTED]> writes:
> This does not:
> pg_dump -h myhost -p 5432 -Fc -f mydb.cpgdmp mydb
> Segmentation fault (core dumped)
If you have any comments on views, this is probably an instance of a
known bug:
2002-12-27 12:10 tgl
* src/bin/pg_dump/: pg_dump.c (REL7_
Oh goodness it's even worse as pg_restore can't read the archive from the
first pg_dump:
pg_dump -h myhost -p 5432 -f mydb.pgdmp mydb
pg_restore -l mydb.pgdmp
pg_restore: [archiver] input file does not appear to be a valid archive
Thanks,
L.
On Fri, 10 Jan 2003, Laurette Cisneros wrote:
>
>
This works:
pg_dump -h myhost -p 5432 -f mydb.cpgdmp mydb
This does not:
pg_dump -h myhost -p 5432 -Fc -f mydb.cpgdmp mydb
Segmentation fault (core dumped)
Nor does this:
pg_dump -h myhost -p 5432 -Ft -f mydb.cpgdmp mydb
(but I need the -Fc badly as my dbs backup up to large files)
Here's a sta
Paul Ramsey <[EMAIL PROTECTED]> writes:
>\d thetable
> returns
>ERROR: Relation "pg_relcheck" does not exist
I think you are using a 7.2 psql with the 7.3 server. There will be
quite a few problems with backslash commands in that combination
(or the reverse), because of the extensive cat
Due to a late-night typo, the 7.3-1 RPMset released last night would start the
postmaster for the first time, but not subsequent times. I have corrected
the problem and uploaded a 7.3-2 RPMset. If you do not want to download the
whole set again to fix a single-character bug, edit the file
/et
On further investigation, the problem is related to using a 7.2 psql
against a 7.3 backend. The \d from the 7.2 psql is not compatible with
the 7.3 backend in the case of tables with non-standard types apparently.
P.
Paul Ramsey wrote:
I am poking around at upgrading PostGIS to work with versi
I am poking around at upgrading PostGIS to work with version 7.3. So
far, the changes seem relatively minor. There is one odd quirk though.
Having gotten the PostGIS types and index bindings loaded, and having
loaded a table full of spatial data, trying to do
\d thetable
returns
ERROR:
I have built and am uploading RPMS for 7.3. Mirror propagation being what it
is, it may take a day or two for these packages to make the rounds.
You may find them at:
ftp://ftp.postgresql.org/pub/binary/v7.3/RPMS
Source RPM in SRPMS, Red Hat 8 RPMS in redhat-8.0. I will be building Red Hat
7.
On Wed, Dec 04, 2002 at 12:22:41AM +, Sigurdur Gunnlaugsson wrote:
>
> test=# move -10 in test_c;
> MOVE 4
> test=# fetch 1 from test_c;
> schemaname | tablename | tableowner | hasindexes | hasrules | hastriggers
> +---+++--+-
>
I don't see any 7.3 tag created when we did the 7.3 release. (I do see
the 7.3 branch.)
Marc, can a tag be added to match the 7.3 release tree?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard dr
On Mon, Dec 02, 2002 at 02:29:03PM -0500, Rod Taylor wrote:
>
> Seems to work the fine for me:
Puzzling...
Would you mind, if you have time, downloading libpqxx from GBorg and
doing a ./configure; make; make check and telling me if tests 19 & 38
succeed? I expect them to have identical results
On Mon, 2002-12-02 at 10:20, Jeroen T. Vermeulen wrote:
> The scenario boils down to: Create a cursor, fetch n rows, move minus 2
> billion or so rows, fetch 1 row. That last fetch used to give me the
> row I was hoping for (the original first row again), but with 7.3 it
> appears to yield nothin
I've been getting reports of one of my test scenarios for libpqxx
failing with postgres 7.3. At the moment I can't reproduce this (I'm
still on 7.2) and I can't find anything pertinent in CVS commit
messages, mailing lists etc. so I'd really appreciate any lucidity from
this list.
My problem appe
Tom/Hackers,
Going back a bit, but relevant with 7.3's release...
Tom Lane writes on 03 Sep 2002:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> >
> > [ original post was regarding the mileage in adding utility
> > functions to PostgreSQL to cut-out common catalog lookups, thus
> > making
I have rebuild HISTORY to add recent release.sgml changes, and have
stamped configure/configure.in for 7.3.
Marc, if you can, please create the 7.3 tarball tonight so the mirrors
will be ready tomorrow. Thanks.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTEC
> I'm seeing this on my Linux box (kernel 2.4.18, glibc 2.2.4):
>
> *** ./expected/horology.out Thu Sep 19 06:35:25 2002
> --- ./results/horology.outMon Oct 28 13:42:39 2002
[snip]
Sorry, this must be due to summer time...
--
Tatsuo Ishii
---(end of broadcast)-
I'm seeing this on my Linux box (kernel 2.4.18, glibc 2.2.4):
*** ./expected/horology.out Thu Sep 19 06:35:25 2002
--- ./results/horology.out Mon Oct 28 13:42:39 2002
***
*** 537,549
SELECT (timestamp with time zone 'today' = (timestamp with time zone 'tomorrow' -
inte
I have copied Tom's fine email to:
http://www.ca.postgresql.org/docs/momjian/upgrade_7.3
and have added a mention of it in the HISTORY file:
A dump/restore using "pg_dump" is required for those wishing to migrate
data from any previous release. A summary of changes needed in cli
Christopher Kings-Lynne wrote:
> > "Jim Buttafuoco" <[EMAIL PROTECTED]> writes:
> > > This seems like a "must" have option for pg_dump,
> > > If I was to create a patch would it make it into 7.3?
> >
> > I dunno ... I'd like to have it too, but it would break our "no new
> > features during beta"
Peter,
On Fri, Sep 06, 2002 at 12:54:13PM +0100, Dave Page wrote:
> Seems to build cleanly here now.
And here (and now) too.
> Perhaps anoncvs just hadn't sync'd up when you tried Jason?
I guess so -- very strange...
Anyway, sorry (again) for the noise and thanks for fixing the Cygwin
build.
age; pgsql-hackers; pgsql-cygwin
> Subject: Re: [HACKERS] 7.3 Beta 1 Build Error on Cygwin
>
>
> Peter,
>
> On Thu, Sep 05, 2002 at 02:51:31PM -0400, Bruce Momjian wrote:
> > Jason Tishler wrote:
> > > On Thu, Sep 05, 2002 at 08:33:20PM +0200, Peter Eisentraut wr
On Thu, 5 Sep 2002, Bruce Momjian wrote:
> I haven't see the beta announcement on the announce list. Do we
> announce it there?
I've been expecting it but haven't seen it yet.
Vince.
--
==
Vince Vielhaber -- KA8CSHema
I haven't see the beta announcement on the announce list. Do we
announce it there?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.
Peter,
On Thu, Sep 05, 2002 at 02:51:31PM -0400, Bruce Momjian wrote:
> Jason Tishler wrote:
> > On Thu, Sep 05, 2002 at 08:33:20PM +0200, Peter Eisentraut wrote:
> > > Should all be fixed now.
> >
> > Huh? I don't see any recent CVS commits to indicate this.
>
> I see as a commit:
>
> [snip]
Jason Tishler wrote:
> Peter,
>
> On Thu, Sep 05, 2002 at 08:33:20PM +0200, Peter Eisentraut wrote:
> > Dave Page writes:
> >
> > > I get the following error when building beta 1 on CYGWIN_NT-5.1 PC9
> > > 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown:
> >
> > Should all be fixed now.
>
> Huh
Peter,
On Thu, Sep 05, 2002 at 08:33:20PM +0200, Peter Eisentraut wrote:
> Dave Page writes:
>
> > I get the following error when building beta 1 on CYGWIN_NT-5.1 PC9
> > 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown:
>
> Should all be fixed now.
Huh? I don't see any recent CVS commits to in
Dave Page writes:
> I get the following error when building beta 1 on CYGWIN_NT-5.1 PC9
> 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown:
Should all be fixed now.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'ki
I get the following error when building beta 1 on CYGWIN_NT-5.1 PC9
1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown:
make[3]: Entering directory
`/usr/local/src/postgresql-7.3b1/src/backend/utils/mb/conversion_procs/c
yrillic_and_mic'
gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations
-I..
Was this going to make it into the release notes or something?
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lane
> Sent: Tuesday, 3 September 2002 9:54 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [HACKER
Lee Kindness <[EMAIL PROTECTED]> writes:
> CREATE OR REPLACE FUNCTION column_exists(NAME, NAME) RETURNS BOOLEAN AS '
> CREATE OR REPLACE FUNCTION table_exists(NAME) RETURNS BOOLEAN AS '
> Obviously these need attention when our application targets 7.3 (and
> thanks for the heads-up), but all c
Tom, do you think there is millage in adding functions (at least to
contrib) to PostgreSQL to avoid some of the common tasks applications
look into pg_* for?
For example I recently audited our code here for pg_* access, and
managed to create two plpgsql functions to replace all
occurrences. They
Bruce suggested that we need a porting guide to help people look for
application and client-library code that will be broken by the changes
in PG 7.3. Here is a first cut at documenting the issues.
Comments welcome --- in particular, what have I missed?
regards, tom lane
On Mon, 2002-09-02 at 09:35, Tatsuo Ishii wrote:
> You need not to specify --enable-syslog in 7.3 BTW.
OK, thanks.
> This happens because the path to shared objs are defined at the
> compile time. I think you don't get the failure once you install
> PostgreSQL. However it's not convenience since
> I'm still getting conversion test failures on RH 7.2, 7.3, and Null beta.
>
> My confiugre arguments are:
>
> ./configure --prefix=/opt/postgresql --with-java --with-python --with-openssl
>--enable-syslog --enable-debug --enable-cassert
> --enable-depend
You need not to specify --enable-sys
I'm still getting conversion test failures on RH 7.2, 7.3, and Null beta.
My confiugre arguments are:
./configure --prefix=/opt/postgresql --with-java --with-python --with-openssl
--enable-syslog --enable-debug --enable-cassert
--enable-depend
It appears that the functions are not being loade
Right now, I am going through my email box trying to resolve any open
patches or items. Once I am done I will let people know. Hopefully
tomorrow we can deal with cleanups and documentation, as well as
anything we missed.
--
Bruce Momjian| http://candle.pha.pa.us
[
On Sat, 31 Aug 2002, Bruce Momjian wrote:
>
> As someone's suggestion, we are going to continue accepting patches
> through Sunday night, EDT, which will give us Monday to make sure all
> the patches are in. I will have the HISTORY/release.sgml ready by then.
>
> At that point, we can collect an
As someone's suggestion, we are going to continue accepting patches
through Sunday night, EDT, which will give us Monday to make sure all
the patches are in. I will have the HISTORY/release.sgml ready by then.
At that point, we can collect any other open items, like doc updates,
and start to se
On Fri, 2002-08-30 at 22:24, Joe Conway wrote:
> Well a "real" fix sounded like a lot of work, and no one had the right
> combination of time/desire/knowledge/skill to go implement it. The
> "workaround" fix was discussed in this more recent thread:
>
> http://archives.postgresql.org/pgsql-hack
Gordon Runkle wrote:
> On Fri, 2002-08-30 at 21:45, Joe Conway wrote:
>
>>That's due to a glibc change and is expected, if not desired. Complain
>>to Red Hat. For more info, see previous threads on HACKERS, notably this
>>one:
>>
>>http://archives.postgresql.org/pgsql-hackers/2002-05/msg00740.p
on RH 7.2, 7.3, and Null Beta.
Here's the important part of the diff of expected (<) and results (>):
6a7
> ERROR: Function iso8859_1_to_utf8 does not exist
11c12
< ERROR: conversion name "myconv" already exists
---
> ERROR: Function iso8859_1_to_utf8 does not exist
15a17
> ERROR: Function i
On Fri, 2002-08-30 at 21:45, Joe Conway wrote:
> That's due to a glibc change and is expected, if not desired. Complain
> to Red Hat. For more info, see previous threads on HACKERS, notably this
> one:
>
> http://archives.postgresql.org/pgsql-hackers/2002-05/msg00740.php
Yeah, I remember that.
Gordon Runkle wrote:
> I know this one has been a pain, but I'm getting regression failures on:
>
> abstime ... FAILED
> tinterval... FAILED
> test horology ... FAILED
>
> under RedHat 7.3 and RedHat Null Beta.
That's due to a glibc change and is e
I know this one has been a pain, but I'm getting regression failures on:
abstime ... FAILED
tinterval... FAILED
test horology ... FAILED
under RedHat 7.3 and RedHat Null Beta.
Thanks,
Gordon.
--
"Far and away the best prize that life has to offer
Looks good now, all three environments (RH 7.2, RH 7.3, RH Null).
G.
On Fri, 2002-08-30 at 20:57, Tom Lane wrote:
> Hmm, I don't get that here. In CVS tip the regression tests pass,
> and a manual trial gives:
>
> test73=# alter table foo drop column bar;
> ERROR: Relation "foo" does not exis
Gordon Runkle <[EMAIL PROTECTED]> writes:
> The alter_table regression test is now failing for me (RH Null).
> It appears that the problem is that the backend is giving back a
> different error message than expected when dropping a column from a
> non-existent table:
> -- try altering non-existen
Thanks, Tom,
My /etc/ld.so.conf didn't have /opt/postgresql/lib in it, yet when I
renamed /opt/postgresql (which was v7.2.2) to something else, the initdb
succeeded. I'm not sure why it went looking up there...
Thanks again,
Gordon.
--
"Far and away the best prize that life has to offer
is
Gordon Runkle <[EMAIL PROTECTED]> writes:
> Running with noclean mode on. Mistakes will not be cleaned up.
>
>/home/gar/src/pgsql/src/test/regress/./tmp_check/install//opt/postgresql/bin/pg_encoding:
> relocation error:
>/home/gar/src/pgsql/src/test/regress/./tmp_check/install//opt/postgresql/bi
[This is an email copy of a Usenet post to "comp.databases.postgresql.hackers"]
I just checked out another CVS snapshot onto a RH 7.2 box, and 'make
check' can successfully do the initdb.
I updated the source on the RH 7.3 box, and still get the initdb failure.
I updated the source on the RH Nu
I just checked out another CVS snapshot onto a RH 7.2 box, and 'make
check' can successfully do the initdb.
I updated the source on the RH 7.3 box, and still get the initdb failure.
I updated the source on the RH Null box, and 'make check' can
successfully do the initdb.
Anyone else having issu
The alter_table regression test is now failing for me (RH Null).
It appears that the problem is that the backend is giving back a
different error message than expected when dropping a column from a
non-existent table:
-- try altering non-existent table, should fail
alter table foo drop column ba
Using current CVS sources (as of 1500 EDT), 'make check' fails at the
database initialization step.
This box is running RH 7.3 with all current RH updates, and has
successfully built Pg 7.2.1 and 7.2.2.
Here's how I'm configuring it (same as I'm doing under the RH Null Beta,
which works fine):
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Has anyone made a decision about the SET LOCAL needing to be changed to SET
> TRANSATION for SQL compatibiltity?
I think we had decided not to; IIRC the argument that spelling it
TRANSACTION would be more spec-compatible looked bogus on clos
Has anyone made a decision about the SET LOCAL needing to be changed to SET
TRANSATION for SQL compatibiltity?
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddre
Iavor Raytchev wrote:
> Hello,
>
> I somehow feel that I do not know anymore what are the current expectations
> for a release date for 7.3.
Beta freeze September 1, final release October/November, is my guess.
> And when do you think it will be stable enough so that testing of interfaces
> (li
Hello,
I somehow feel that I do not know anymore what are the current expectations
for a release date for 7.3.
And when do you think it will be stable enough so that testing of interfaces
(like pgaccess) will be meaningful (is this the period you call 'slow
down').
Iavor
--
www.pgaccess.org
I have added these emails to TODO.detail/prepare.
---
Karel Zak wrote:
> On Fri, Apr 12, 2002 at 12:41:34AM -0400, Neil Conway wrote:
> > On Fri, 12 Apr 2002 12:58:01 +0900
> > "Hiroshi Inoue" <[EMAIL PROTECTED]> wrote:
> >
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Top ten calls:
> % cumulative self self total
> time seconds secondscalls ms/call ms/call name
> 36.95 9.87 9.87 74882482 0.00 0.00 pq_getbyte
> 22.80 15.96 6.09 11 553.64 1450.9
Peter Eisentraut wrote:
> The string literals didn't contain any backslashes, so scanstr is
> operating in the best-case scenario here. But for arbitary binary data we
> need some escape mechanism, so I don't see much room for improvement
> there.
>
> It seems the real bottleneck is the excessiv
Tom Lane writes:
> The regression tests contain no very-long literals. The results I was
> referring to concerned cases with string (BLOB) literals in the
> hundreds-of-K range; it seems that the per-character loop in the flex
> lexer starts to look like a bottleneck when you have tokens that mu
On Sun, 14 Apr 2002, Barry Lind wrote:
> But since the syntax for prepare is: PREPARE AS you
> can't easily reuse sql prepared by other PreparedStatement objects since
> you don't know if the sql you are about to execute has or has not yet
> been prepared or what was used in that prepare. T
Curt Sampson wrote:
> On Thu, 11 Apr 2002, Barry Lind wrote:
>
>
>>I'm not sure that JDBC would use this feature directly. When a
>>PreparableStatement is created in JDBC there is nothing that indicates
>>how many times this statement is going to be used. Many (most IMHO)
>>will be used only
On Thu, 11 Apr 2002, Barry Lind wrote:
> I'm not sure that JDBC would use this feature directly. When a
> PreparableStatement is created in JDBC there is nothing that indicates
> how many times this statement is going to be used. Many (most IMHO)
> will be used only once.
Well, the particular
On 13 Apr 2002, Hannu Krosing wrote:
> On Fri, 2002-04-12 at 03:04, Brian Bruns wrote:
> > On 11 Apr 2002, Hannu Krosing wrote:
> >
> > > IIRC someone started work on modularising the network-related parts with
> > > a goal of supporting DRDA (DB2 protocol) and others in future.
> >
> > That wa
On Fri, Apr 12, 2002 at 12:51:26PM -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Certainly a shared cache would be good for apps that connect to issue a
> > single query frequently. In such cases, there would be no local cache
> > to use.
>
> We have enough other problem
On Sat, 13 Apr 2002 14:21:50 +0800
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> wrote:
> Could this cache mechanism be used to make views fast as well?
The current PREPARE/EXECUTE code will speed up queries that use
rules of any kind, including views: the query plan is cached after
it has been r
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> thought out way of predicting/limiting their size. (2) How the heck do
> you get rid of obsoleted cached plans, if the things stick around in
> shared memory even after you start a new backend? (3) A shared cache
> requires locking; content
On Fri, 2002-04-12 at 03:04, Brian Bruns wrote:
> On 11 Apr 2002, Hannu Krosing wrote:
>
> > IIRC someone started work on modularising the network-related parts with
> > a goal of supporting DRDA (DB2 protocol) and others in future.
>
> That was me, although I've been bogged down lately, and hav
> > thought out way of predicting/limiting their size. (2) How the heck do
> > you get rid of obsoleted cached plans, if the things stick around in
> > shared memory even after you start a new backend? (3) A shared cache
> > requires locking; contention among multiple backends to access that
> >
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> My profiles show that the work spent in the scanner is really minuscule
> compared to everything else.
Under ordinary circumstances I think that's true ...
> (The profile data is from a run of all the regression test files in order
> in one session.
1 - 100 of 136 matches
Mail list logo
