I'm pretty new to postgresql.. I'm using a fresh compile/install of postgresql 7.1.2
without any special options.. but here's my problem:
semantic=# create temp table ttmptable(lookup_id int, rating int);
CREATE
semantic=# SELECT doEverythingTemp(20706,2507);
doeverythingtemp
pg_dump/pg_dumpall fail with the following messages (verbose output
selected):
...
-- dumping out user-defined procedural languages
-- dumping out user-defined functions
failed sanity check, type with oid 59770787 was not found
OS: Linux kernel 2.2.16
PostgreSQL v. 7.0.3
I've seen similar
\(::\) Bob Ippolito [EMAIL PROTECTED] writes:
semantic=# DROP table ttmptable;
DROP
semantic=# create temp table ttmptable(lookup_id int, rating int);
CREATE
semantic=# SELECT doEverythingTemp(20706,2507);
ERROR: Relation 4348389 does not exist
Yeah, temp tables and plpgsql functions
Hi !
My system is i686/Linux Mandrake 7.0/Postgresql v-7.0.2.
I found a bug in the sql command ALTER TABLE ADD CONSTRAINT..., when I tried to add a
composite foreign key constraint
(a FK with more than one attribute). The problem is in the file identified by
$Header:
Hi !
My system is i686/Linux Mandrake 7.0/Postgresql v-7.0.2.
I found a bug in the sql command ALTER TABLE ADD CONSTRAINT..., when I tried to add a
composite foreign key constraint
(a FK with more than one attribute). The problem is in the file identified by
$Header:
On Thursday 19 July 2001 06:08, you wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think it should be off on user tables by default, but kept on system
tables just for completeness. It could be added at table creation time
or from ALTER TABLEL ADD. It seems we just use them too much for
jozzano [EMAIL PROTECTED] writes:
My system is i686/Linux Mandrake 7.0/Postgresql v-7.0.2.
I found a bug in the sql command ALTER TABLE ADD CONSTRAINT...,
This bug seems to be already fixed in release 7.1.
regards, tom lane
---(end of
Has anyone here thought about using the spread libraries for WAL
replication amongst mutliple hosts? With this library I think it'd be
possible to have a multi-master replication system...
http://www.spread.org/
I'm not familiar enough with the guts of postgres to be able to
Howdy. Darren, I'd reply in person, but there are issues with
your mail account. ;~) At anyrate, is there a mailing list that the
Postgres-R development is happening on so that I could drop in and
either listen/contribute? Thanks. -sc
[EMAIL PROTECTED]:
63.136.234.38 does not like
Sure. The mailing list is
http://www.greatbridge.org/mailman/listinfo/pgreplication-general
It's not only for Postgres-R, but any PostgreSQL
replication ideas, discussions, or projects.
Feel free to listen or contribute.
Darren
BTW: My apologies for the email issues. Should be fixed now.
Tom mentioned what should be stored in the OID system column if no oid's
are in the table. He also mentioned that he doesn't want a
variable-length tuple header so will always have an oid system column.
What about moving the oid column out of the tuple header. This saves 4
bytes in the header
As I mentioned already I'm implementing updatable cursors
in ODBC and have half done it. If OIDs would be optional
my trial loses its validity but I would never try another
implementation.
But how can you do that ? The oid index is only created by
the dba for specific tables, thus your
Reported by Tatsuo with 1000 backends all waking up at the same time:
* Create spinlock sleepers queue so everyone doesn't wake up at once
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a
Steve Howe [EMAIL PROTECTED] writes:
I downloaded the PostgreSQL v7.12 sources, compiled libpq.dll using
Microsoft's Visual C++ 6.0, and tried sending a large query.
The problem is, when the query is 8192 large, a NULL pointer is
returned from PQexec().
It sure sounds to me
On Friday 20 July 2001 08:09, The Hermit Hacker wrote:
there, and I just cleared out about 500Meg+ of old garbage ... 1.2gig free
again ...
Unless I get protests to the contrary, I'm going to remove all but the last
supported RPM versions in /pub/binary for each major version. IE, all but
Hello all,
I've tried again sending large queries using libpq on Windows
environment, without success.
I downloaded the PostgreSQL v7.12 sources, compiled libpq.dll using
Microsoft's Visual C++ 6.0, and tried sending a large query.
The problem is, when the query is 8192
Tom Lane wrote:
What's wrong with 64-bit oids (except extra 4bytes)?
Portability, mostly.
Oh, there's one other small problem: breaking the on-the-wire protocol.
So 8-byte-OID is for PostgreSQL 8? :-)
--
Alessio F. Bragadini[EMAIL PROTECTED]
APL Financial Services
On Thu, 19 Jul 2001, Tom Lane wrote:
Hi Tom,
I removed an ISO that Corey had made for me, that should free up some
space.
/home/projects/pgsql partition at hub.org is down to zero free space...
regards, tom lane
---(end of
On Fri, 20 Jul 2001, Chris Bowlby wrote:
On Thu, 19 Jul 2001, Tom Lane wrote:
Hi Tom,
I removed an ISO that Corey had made for me, that should free up some
space.
And I removed some stuff.
Vince.
/home/projects/pgsql partition at hub.org is down to zero free space...
Does anyone know if it is possible to define a Postgres C function as taking a
variable number of parameters? The fmgr code will pass it, but I don't see any
way to use create function to register it.
Does one have to issue a create function for each additional parameter?
I am trying to port
Someone on IRC just mentioned that mere mortals can create tables in
template1. If the user restricts template1 access to users via
pg_hba.conf, certain commands will not work that use template1
connection.
Any solutions? I think we need table creation permissions even if we
don't overhaul
Steve Howe [EMAIL PROTECTED] writes:
Nope, I'm 100% sure that the libpq.dll used is the one I just
compiled. And I never installed an older libpq.dll on this system.
Hmph. So what is left in PQerrorMessage() after the failure?
regards, tom lane
Bruce Momjian [EMAIL PROTECTED] writes:
What about moving the oid column out of the tuple header. This saves 4
bytes in the header in cases where there is no oid on the table.
No it doesn't --- at least not on machines where MAXALIGN is eight
bytes.
I don't think this is worth the trouble...
Steve Howe [EMAIL PROTECTED] writes:
It returns Error: pqReadData() -- read() failed: errno=0 No error
as expected when a nil pointer is returned.
As expected? That's not what I'd expect, especially not for a
behavior that's dependent on the size of an *outgoing* message.
(Thinks
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Steve Howe [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, July 20, 2001 5:17 PM
Subject: Re: [HACKERS] Large queries - again...
Steve Howe [EMAIL PROTECTED] writes:
It returns Error: pqReadData() -- read()
[cc: to GENERAL replacedby cc: to HACKERS]
On Friday 20 July 2001 17:14, Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
The biggest patching by far is
in the regression tests, which really are not designed to live outside
the source tree, but can be munged into shape fairly easily.
Lamar Owen [EMAIL PROTECTED] writes:
Ok, let's look. First, there is a createlang issue: during build, @libdir@
as referenced in the createlang script references /usr/lib, instead of
/usr/lib/pgsql, which is desired.
Okay, that problem is gone in current sources, anyway (createlang no
As expected? That's not what I'd expect, especially not for a
behavior that's dependent on the size of an *outgoing* message.
It is expected, because it's the default message when a PQexec() query
returns NULL: pqReadData() will return nothing yet no error is signed.
Of course, the really
Tom Lane [EMAIL PROTECTED] writes:
BTW, the only python shebangs I can find in CVS look like
#! /usr/bin/env python
Isn't that OK on RedHat?
It is.
--
Trond Eivind Glomsrød
Red Hat, Inc.
---(end of broadcast)---
TIP 5: Have you checked
Steve Howe [EMAIL PROTECTED] writes:
(Thinks for awhile...) You're not using PQsetnonblocking() are you,
by any chance?
No, I'm not.
Drat, another perfectly good theory down the drain :-(.
Well, we're not going to find out anymore until we discover what the
error code actually is --- the
On Fri, Jul 20, 2001 at 07:05:46PM -0400, Trond Eivind Glomsr?d wrote:
Tom Lane [EMAIL PROTECTED] writes:
BTW, the only python shebangs I can find in CVS look like
#! /usr/bin/env python
Isn't that OK on RedHat?
It is.
Probably the perl scripts should say, likewise,
On Friday 20 July 2001 18:45, Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
On to the next batch There are a few perl and python scripts shipped
as examples -- every last one of them shebangs to '/usr/local/perl' or
'/usr/local/python' -- to make them usable, I patch this to
Lamar Owen [EMAIL PROTECTED] writes:
How is this search path defined? Blindly using libdir is not ok --
Why not?
The search path is defined in postgresql.conf (and I see Peter forgot
to add an example to the postgresql.conf.sample file), but the default
is the backend-compile-time $libdir.
On to the next batch There are a few perl and python scripts shipped as
examples -- every last one of them shebangs to '/usr/local/perl' or
'/usr/local/python' -- to make them usable, I patch this to '/usr/bin/perl'
or python, as appropriate.
Hmm. Given that they're only examples,
Steve Howe [EMAIL PROTECTED] writes:
(Thinks for awhile...) You're not using PQsetnonblocking() are you,
by any chance?
No, I'm not.
Drat, another perfectly good theory down the drain :-(.
Well, we're not going to find out anymore until we discover what the
error code actually is
OK, I just applied a patch to add the final fixes to Win32 libpq.
Please try the CVS or later snapshot to see how it works. The patch
suggested adding
#define snprintf _snprintf
to win32.h and I have done that. There was already one there for
vsnprintf. I am quite confused about
- Original Message -
From: Bruce Momjian [EMAIL PROTECTED]
To: Steve Howe [EMAIL PROTECTED]
Cc: Tom Lane [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Saturday, July 21, 2001 1:39 AM
Subject: Re: [HACKERS] Large queries - again...
OK, I just applied a patch to add the final fixes to
Well, I tested the query you sent, and I got these results accessing the
data:
1) libpq from Windows (freshly compiled from 7.1.2 sources): Error:
pqReadData() -- read() failed: errno=0
No error
2) ODBC from Windows: It works ok.
Steve Howe [EMAIL PROTECTED] escreveu nas notícias de
mlw [EMAIL PROTECTED] writes:
Does anyone know if it is possible to define a Postgres C function as
taking a variable number of parameters? The fmgr code will pass it,
but I don't see any way to use create function to register it.
No, it's not. There is some (purely speculative) support for
Straight out of Allied peace talks, we've got this article up at mysql.com
http://www.mysql.com/news/article-76.html
One wonders what happened to the postal or email systems that this couldn't
have been delivered privately.
In all honesty, it appears mysql.org was overdue, the level of rhetoric
Hello Tom,
It returns Error: pqReadData() -- read() failed: errno=0 No error
as expected when a nil pointer is returned.
Best Regards,
Steve Howe
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Steve Howe [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, July
Hello Tom,
Nope, I'm 100% sure that the libpq.dll used is the one I just
compiled. And I never installed an older libpq.dll on this system.
My application loads specifically the libpq.dll I compiled (I use
the full library path on the call to LoadLibrary() call, so there is no
Just another way to get your name on the top 10 lists, eh?
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
43 matches
Mail list logo
