RE: OID wraparound (was Re: [HACKERS] pg_depend)
> -Original Message- > Zeugswetter Andreas SB > > > 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 update would do an update > with a where restriction, that is not indexed. > This would be darn slow, no ? > Please look at my another(previous ?) posting to pgsql-hackers. I would use both TIDs and OIDs, TIDs for fast access, OIDs for identification. > How about instead selecting the primary key and one of the tid's > (I never remember which, was it ctid ?) instead, so you can validate > when a row changed between the select and the update ? > Xmin is also available for row-versioning. But now I'm wondering if TID/xmin are guranteed to keep such characteriscs. Even Object IDentifier is about to lose the existence. Probably all-purpose application mustn't use system columns at all though I've never heard of it in other dbms-s. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IDEA: Multi-master replication possible through spread (or even master-slave)...
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. Sean Chittenden wrote: > 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Large queries - again...
- 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 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 the elog() mention. I don't see > where we added a call to elog() in the past day. I only see two > mentions of elog in the code, both it dllist.c. They don't use elog() > if you define FRONTEND. Please do -DFRONTEND on the compile line. I > think this will give you a good library binary. I did it, but that brings other dependency problems (see below). I think it's better to properly fix the elog issue... :-) C:\ttt\src>nmake -f win32.mak Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cd include if not exist config.h copy config.h.win32 config.h cd .. cd interfaces\libpq nmake /f win32.mak Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cl.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\nma01700. dllist.c ..\..\backend\lib\dllist.c(20) : fatal error C1083: Cannot open include file: 'sysexits.h': No such file or directory > Let us know how the new code works. The most recent patch I just > applied was tested by a user and it worked well for him. Nice to have > this resolved. I can mark this TODO item as done: > > * -Fix libpq to properly handle socket failures under native MS > Win32 [libpq] I want this fixed more then anybody else i the world, believe me :-) Best Regards, Steve Howe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] IDEA: Multi-master replication possible through spread (or even master-slave)...
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 recipient. Remote host said: 550 <[EMAIL PROTECTED]>... User unknown Giving up on 63.136.234.38. --- Below this line is a copy of the message. Return-Path: <[EMAIL PROTECTED]> Received: (qmail 9478 invoked by uid 1001); 21 Jul 2001 05:09:21 - Date: Fri, 20 Jul 2001 22:09:21 -0700 From: Sean Chittenden <[EMAIL PROTECTED]> To: Darren Johnson <[EMAIL PROTECTED]> Subject: Re: [HACKERS] IDEA: Multi-master replication possible through spread +(or even master-slave)... Message-ID: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> +<[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1ppIqr1kl39GnwQx" Content-Disposition: inline In-Reply-To: <[EMAIL PROTECTED]>; from "[EMAIL PROTECTED]" +on Sat, Jul 21, 2001 at = 01:01:58AM On Sat, Jul 21, 2001 at 01:01:58AM -0400, Darren Johnson wrote: > Delivered-To: [EMAIL PROTECTED] > Date: Sat, 21 Jul 2001 01:01:58 -0400 > From: Darren Johnson <[EMAIL PROTECTED]> > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010131 >Netscape6/6.01 > X-Accept-Language: en > To: Sean Chittenden <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED] > Subject: Re: [HACKERS] IDEA: Multi-master replication possible through spread (or >even master-slave)... > > Sean Chittenden wrote: > > > 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.. > > Yes, there is some work being done to use Spread as the group > communication system > for Postgres-R, but we are just getting started with this software. > Using a group > communication system to establish total order messages is one of the > basic principles for > synchronous multi-master replication with Postgres-R. Currently > Ensemble (form Cornell > University) is used, but Spread looks to be more robust and it appears > to be supported > on most if not all of the PostgreSQL supported platforms. > > It's very cool to see positive testimony for Spread, and I hope I will > feel the same way > as I become more familiar with it. -- Sean Chittenden PGP signature ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Large queries - again...
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 the elog() mention. I don't see where we added a call to elog() in the past day. I only see two mentions of elog in the code, both it dllist.c. They don't use elog() if you define FRONTEND. Please do -DFRONTEND on the compile line. I think this will give you a good library binary. Let us know how the new code works. The most recent patch I just applied was tested by a user and it worked well for him. Nice to have this resolved. I can mark this TODO item as done: * -Fix libpq to properly handle socket failures under native MS Win32 [libpq] > > "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 "errno=0" bogosity isn't helping. > > As Bruce mentioned, we did just commit a patch that #defines errno > > as WSAGetLastError() on WIN32, so that you can get at least something > > useful about socket errors. I'd suggest pulling the current CVS sources > > (or a nightly snapshot tarball dated after today) and building libpq > > from that. Then maybe we can learn more. > Unhappyly, there are unresolved externals and it won't build... > I'll try to fix it. > The log follows right below... > > Best regards, > Steve Howe > > > -- > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > cd include > if not exist config.h copy config.h.win32 config.h > cd .. > cd interfaces\libpq > nmake /f win32.mak > > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > link.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\nma01588. >Creating library .\Release\libpqdll.lib and object .\Release\libpqdll.exp > libpq.lib(fe-exec.obj) : error LNK2001: unresolved external symbol _snprintf > libpq.lib(fe-misc.obj) : error LNK2001: unresolved external symbol _snprintf > libpq.lib(fe-auth.obj) : error LNK2001: unresolved external symbol _snprintf > libpq.lib(dllist.obj) : error LNK2001: unresolved external symbol _elog > .\Release\libpq.dll : fatal error LNK1120: 2 unresolved externals > NMAKE : fatal error U1077: 'link.exe' : return code '0x460' > Stop. > NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual > Studio\VC98\bin\NMAKE.EXE"' : return > code '0x2' > Stop. > > > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Large queries - again...
> "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 "errno=0" bogosity isn't helping. > As Bruce mentioned, we did just commit a patch that #defines errno > as WSAGetLastError() on WIN32, so that you can get at least something > useful about socket errors. I'd suggest pulling the current CVS sources > (or a nightly snapshot tarball dated after today) and building libpq > from that. Then maybe we can learn more. Unhappyly, there are unresolved externals and it won't build... I'll try to fix it. The log follows right below... Best regards, Steve Howe -- Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cd include if not exist config.h copy config.h.win32 config.h cd .. cd interfaces\libpq nmake /f win32.mak Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. link.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\nma01588. Creating library .\Release\libpqdll.lib and object .\Release\libpqdll.exp libpq.lib(fe-exec.obj) : error LNK2001: unresolved external symbol _snprintf libpq.lib(fe-misc.obj) : error LNK2001: unresolved external symbol _snprintf libpq.lib(fe-auth.obj) : error LNK2001: unresolved external symbol _snprintf libpq.lib(dllist.obj) : error LNK2001: unresolved external symbol _elog .\Release\libpq.dll : fatal error LNK1120: 2 unresolved externals NMAKE : fatal error U1077: 'link.exe' : return code '0x460' Stop. NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\VC98\bin\NMAKE.EXE"' : return code '0x2' Stop. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] IDEA: Multi-master replication possible through spread (or even master-slave)...
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 impliment this (yet), but thought that it might be something for someone else to look into. At the very least, check out the libs, they're very impressive and I've had good luck with them in the past. If push comes to shove, in a few months I may write a few ruby+spread utils to do this, but we'll see... -sc -- Sean Chittenden PGP signature ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)
> > 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, and are clearly going to be
> broken until hand-edited on many systems not only RedHat, it's not clear
> that this is worth your worrying about.
Ack! There is a way to write this stuff to be portable. The tricks
change a bit depending on the scripting language you are using, but for
perl this is how the header should look:
#!/bin/sh
# -*- perl -*-
# the line above helps with emacs, and put other comments here...
eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$@"}'
& eval 'exec perl -S $0 $argv:q'
if 0;
# real perl code follows...
There is no reason to have a dependency on anything but the location of
sh, which is much more reliable than locations for perl, tcl, etc etc.
Not sure the exact form of this technique for python (maybe the same as
above) but there is a similar but not identical form for tcl code
(examples available on request; the above for perl is demonstrated in
contrib/rserv/*.in).
- Thomas
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)
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. Offhand I don't see what's wrong with it. > libdir!=PGLIB, and PGLIB may not be defined in the environment -- it > might be there, but we can't count on it. AFAICT we do not depend on environment PGLIB any more. Configure-time $libdir is what counts. > If this function search path can be configured to search in > /usr/lib/pgsql and all or any of its subs, while libpq and kin live in > /usr/lib, I _will_ be happy. I think all you need to do is set up postgresql.conf that way. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)
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 > > '/usr/bin/perl' or python, as appropriate. > Hmm. Given that they're only examples, and are clearly going to be > broken until hand-edited on many systems not only RedHat, it's not clear Well, there were more than just a few at one point. In any case, it's been awhile since I combed through the example scripts -- of which I only now ship the one, which is designed to test the perl client -- which I find to be a useful thing. > BTW, the only python shebangs I can find in CVS look like > #! /usr/bin/env python > Isn't that OK on RedHat? Yeah, that construct is OK. 7.0.x was different, unless I'm far off-base. But I'm not shipping any patched python scripts with 7.1.x anyway -- the 6.5.x and 7.0.x dists had some scripts with #!/usr/local/bin/python. So much for my 'every last one,' eh? :-) > Much of this could be eliminated given the new path-searching behavior > for CREATE FUNCTION, I think. Actually I thought Peter had cleaned it > up already, but I see he hasn't touched the regression tests. How is this search path defined? Blindly using libdir is not ok -- libdir!=PGLIB, and PGLIB may not be defined in the environment -- it might be there, but we can't count on it. > IMHO we > could have "make installcheck" copy the .so files to $LIBDIR, libdir!=PGLIB for the RPMs. libdir=/usr/lib; PGLIB=/usr/lib/pgsql. I was so happy when the bki sources were no longer referenced by PGLIB -- when the procedural language handlers aren't thusly referenced will be a Happy Day. If PGLIB could = libdir, and something like PGHANDLER= where the handlers live, I'd also be happy. If this function search path can be configured to search in /usr/lib/pgsql and all or any of its subs, while libpq and kin live in /usr/lib, I _will_ be happy. > and then > the regression test input and output files themselves wouldn't need to > know these paths at all. (OTOH, there'd still be paths in the COPY > commands. Would it be okay to eliminate testing of backend COPY and > instead make these regression tests use psql \copy?) The COPY paths are munged into form by the GNUmakefile patch -- so, if the GNUmakefile can generally deal with the paths by placing relative paths (relative to what, though?) in the @abs_srcdir@/@abs_builddir@ substitutions, then those paths aren't an issue. Although a psql \copy regression test might be a good thing in its own right. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)
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, #!/usr/bin/env perl Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Large queries - again...
"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 "errno=0" bogosity isn't helping. As Bruce mentioned, we did just commit a patch that #defines errno as WSAGetLastError() on WIN32, so that you can get at least something useful about socket errors. I'd suggest pulling the current CVS sources (or a nightly snapshot tarball dated after today) and building libpq from that. Then maybe we can learn more. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)
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 our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Large queries - again...
> > "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 expected" would be a sucessfull exec :-) > > > (Thinks for awhile...) You're not using PQsetnonblocking() are you, > > by any chance? > No, I'm not. Asynchronous libpq connections on Windows are still not > realiable (althought I read someone submitted a patch recently), so I'm > keeping synchronous queries for a while. I'm not also using any non-standard > functions; just plain PQconnectdb() and PQexec()... Yes, just applied. I will have another one next week. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)
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 longer needs to know any absolute paths). > 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, and are clearly going to be broken until hand-edited on many systems not only RedHat, it's not clear that this is worth your worrying about. But by the same token, I wouldn't have a problem with applying that change to the masters --- surely there are as many systems where '/usr/bin/perl' is correct as there are where the other is correct. (In fact, a quick grep shows that we have more '/usr/bin/perl' than '/usr/local/bin/perl' in the distribution, so your claim that they're all the latter is mistaken. We should certainly try to make them consistent, whichever is preferred.) BTW, the only python shebangs I can find in CVS look like #! /usr/bin/env python Isn't that OK on RedHat? > Now to the regression tests. First off, I: > define sed-command > -sed -e 's,@abs_srcdir@,$(abs_srcdir),g' \ > --e 's,@abs_builddir@,$(abs_builddir),g' \ > +sed -e 's,@abs_srcdir@,/usr/lib/pgsql/test/regress,g' \ > +-e 's,@abs_builddir@,/usr/lib/pgsql/test/regress,g' \ > -e 's/@DLSUFFIX@/$(DLSUFFIX)/g' $< >$@ > endef Clearly, this needs to be generalized ... > Then, I: > - AS '@abs_builddir@/regress@DLSUFFIX@' > + AS '/usr/lib/pgsql/test/regress/regress.so' > everywhere that is used, along with its likenesses pointing to refint.so and > autoinc.so, which I prebuild and stuff into /usr/lib/pgsql/test/regress. Much of this could be eliminated given the new path-searching behavior for CREATE FUNCTION, I think. Actually I thought Peter had cleaned it up already, but I see he hasn't touched the regression tests. IMHO we could have "make installcheck" copy the .so files to $LIBDIR, and then the regression test input and output files themselves wouldn't need to know these paths at all. (OTOH, there'd still be paths in the COPY commands. Would it be okay to eliminate testing of backend COPY and instead make these regression tests use psql \copy?) regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)
[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.
> Peter has already done good work in making it possible to build outside
> the source tree. ISTM that it would make logical sense to allow
> regression tests to be run outside the source tree as well, as long as
> the changes don't break the existing procedures. I have not looked at
> your patches in this area --- what do they need to do, exactly?
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. So the first patch is:
diff -uNr postgresql-7.1.2.orig/src/bin/scripts/createlang.sh
postgresql-7.1.2/src/bin/scripts/createlang.sh
--- postgresql-7.1.2.orig/src/bin/scripts/createlang.sh Sun Feb 18 13:34:01
2001
+++ postgresql-7.1.2/src/bin/scripts/createlang.sh Wed Jun 13 16:00:55 2001
@@ -164,7 +164,7 @@
# Check that we have PGLIB
# --
if [ -z "$PGLIB" ]; then
- PGLIB='@libdir@'
+ PGLIB='/usr/lib/pgsql'
fi
# --
To handle that, as $PGLIB does indeed point to /usr/lib/pgsql for most
things, but a user is not guaranteed to set the envvar. @libdir@ points to
/usr/lib during the build, as it should -- but createlang's PGLIB and
autoconf's libdir are not equal.
This is desireable because the procedural languages aren't generally loadable
into any arbitrary program by ld.so; rather, they are postgresql-specifc
modules, warranting a separate directory under FHS. This patch fixes the
RPM-specific case only, obviously, as /usr/lib/pgsql is going to be the wrong
choice for non-RPM users :-).
Next, we have patches to make the perl client honor RPM_BUILD_ROOT (otherwise
known as DESTDIR). I'm omitting them here, as Peter has mentioned a build
overhaul for the perl and python clients to make them do DESTDIR and in
general fit in better with the rest of the package.
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. I only ship
postgresql-7.1.2/src/interfaces/perl5/test.pl at this time.
Now to the regression tests. First off, I:
diff -uNr postgresql-7.1.2.orig/src/test/regress/GNUmakefile
postgresql-7.1.2/src/test/regress/GNUmakefile
--- postgresql-7.1.2.orig/src/test/regress/GNUmakefile Wed Apr 4 17:15:56
2001
+++ postgresql-7.1.2/src/test/regress/GNUmakefile Wed Jun 13 16:00:55 2001
@@ -67,8 +67,8 @@
abs_builddir := $(shell pwd)
define sed-command
-sed -e 's,@abs_srcdir@,$(abs_srcdir),g' \
--e 's,@abs_builddir@,$(abs_builddir),g' \
+sed -e 's,@abs_srcdir@,/usr/lib/pgsql/test/regress,g' \
+-e 's,@abs_builddir@,/usr/lib/pgsql/test/regress,g' \
-e 's/@DLSUFFIX@/$(DLSUFFIX)/g' $< >$@
endef
since the tests aren't in the build tree anymore, but in
/usr/lib/pgsql/test/regress. Well _technically_ they're really NOT in
/usr/lib/pgsql/test/regress, but in DESTDIR/usr/lib/pgsql/test/regress during
the build -- but they will be executed in the coded location after the RPM
installation.
Then, I:
- AS '@abs_builddir@/regress@DLSUFFIX@'
+ AS '/usr/lib/pgsql/test/regress/regress.so'
everywhere that is used, along with its likenesses pointing to refint.so and
autoinc.so, which I prebuild and stuff into /usr/lib/pgsql/test/regress.
Although /usr/lib/pgsql would be a more consistent place, I guess. That
construct is used in
postgresql-7.1.2/src/test/regress/input/create_function_1.source and
ostgresql-7.1.2/src/test/regress/output/create_function_1.source.
Finally, I patch postgresql-7.1.2/src/test/regress/pg_regress.sh:
@@ -69,7 +69,7 @@
: ${inputdir=.}
: ${outputdir=.}
-libdir='@libdir@'
+libdir='/usr/lib/pgsql'
bindir='@bindir@'
datadir='@datadir@'
host_platform='@host_tuple@'
Again, @libdir@ != $PGLIB.
This set is quite a bit smaller than the 7.0.x and 6.5.x sets, thanks in no
small part to Peter's work, as you have already said.
> I think there are really two separate discussions going on here: one is
> whether we shouldn't try harder to roll some of the RPMset diffs back
> into the main sources, and the other is how we can make information
> about some of the popular packages more readily visible/available to the
> developers.
My diffs are nowhere near as large as the debian set. There are other things
I could patch, instead of frobbing in the specfile, though -- things like the
python and perl clients' makefile's DESTDIR ignorance, and the fact that
'make install' puts the procedural languages in /usr/lib instead of
/usr/lib/pgsql. The easy answer: 'Use the --libdir configure
Re: [HACKERS] Large queries - again...
- 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() 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. 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 expected" would be a sucessfull exec :-) > (Thinks for awhile...) You're not using PQsetnonblocking() are you, > by any chance? No, I'm not. Asynchronous libpq connections on Windows are still not realiable (althought I read someone submitted a patch recently), so I'm keeping synchronous queries for a while. I'm not also using any non-standard functions; just plain PQconnectdb() and PQexec()... Best Regards, Steve ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Large queries - again...
"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 for awhile...) You're not using PQsetnonblocking() are you, by any chance? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Large queries - again...
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 20, 2001 2:42 PM Subject: Re: [HACKERS] Large queries - again... > "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 > ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Large queries - again...
"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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] C functions
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 the idea in the fmgr code, but none anywhere else, as yet. > Does one have to issue a create function for each additional parameter? Yup, you could make multiple pg_proc entries all pointing at the same C function. Kinda grotty, but... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Large queries - again...
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 way it is an older library. Eduardo Stern from dbExperts (http://www.dbexperts.com.br), a PostgreSQL specialized consulting company, got the same results. The ODBC driver, however, do not suffer from the same problem, once it does not use libpq. Maybe I should write a C sample that proves libpq under windows has this bug ??? Best Regards, Steve Howe - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Steve Howe" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, July 20, 2001 12:35 PM Subject: Re: [HACKERS] Large queries - again... > "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 like you are invoking an old (6.5 or before) libpq. > Perhaps you should check around to see if there are multiple libpq.dll > files on your system ... > > regards, tom lane > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] BUG (fixed) in CREATE TABLE ADD CONSTRAINT...(v-7.0.2)
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 broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Neutral Soil (OT)
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 coming from MySQL AB is incredible. Perhaps Postgresql folks could start thinking of peace talk sites as well? I recommand the tropics. Then all that's left is to find something to fight about to justify a flight down to paradise. AZ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: OID wraparound (was Re: [HACKERS] pg_depend)
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 system > stuff. pg_description is just one example. and what difference should it make, to have a few extra hundred or thousand OIDs used by system tables, when I insert daily some ten thousand records each using an OID for itself? Why not make OIDs 64 bit? Might slow down a little on legacy hardware, but in a couple of years we'll all run 64 bit hardware anyway. I believe that just using 64 bit would require the least changes to Postgres. Now, why would that look that obvious to me and yet I saw no mentioing of this in the recent postings. Surely it has been discussed before, so which is the point I miss or don't understand? I would need 64 bit sequences anyway, as it is predictable that our table for pathology results will run out of unique IDs in a couple of years. Horst ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: All computers in the world MUST sync with ATOMIC clock before 12:00 AM 21 July 2001!!!
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
[HACKERS] BUG (fixed) in CREATE TABLE ADD CONSTRAINT...(v-7.0.2)
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: /home/projects/pgsql/cvsroot/pgsql/src/backend/commands/command.c,v 1.71
2000/04/12 17:14:57 momjian Exp $
in the code lines #1139 to #1150, when the function AlterTableAddConstraint() tries to
construct the vector of the trigger´s tgargs.
>From the position 4 and forward, it must collect the pairs of fk_attrs and pk_attrs
>(interleaved), but the current code put first all
fk_attrs and then all the pk_attrs, leading to an error.
I fixed the bug and tested the update and now it works well. I send you a "diff -c
command.c command.fixed.c" (with the diff :
GNU diffutils version 2.7) and the output is:
*** command.c Sun May 6 21:13:06 2001
--- command.fixed.c Mon Jul 9 19:58:21 2001
***
*** 19,24
--- 19,25
* manipulating code in the commands/ directory, should go
* someplace closer to the lib/catalog code.
*
+ *
*-
*/
#include "postgres.h"
***
*** 1138,1152
{
Ident *fk_at = lfirst(list);
! trig.tgargs[count++] = fk_at->name;
}
foreach(list, fkconstraint->pk_attrs)
{
Ident *pk_at = lfirst(list);
! trig.tgargs[count++] = pk_at->name;
}
! trig.tgnargs = count;
scan = heap_beginscan(rel, false, SnapshotNow, 0,
NULL);
AssertState(scan != NULL);
--- 1139,1156
{
Ident *fk_at = lfirst(list);
! trig.tgargs[count] = fk_at->name;
! count+=2;
}
+ count = 5;
foreach(list, fkconstraint->pk_attrs)
{
Ident *pk_at = lfirst(list);
! trig.tgargs[count] = pk_at->name;
! count+=2;
}
! trig.tgnargs = (count-1);
scan = heap_beginscan(rel, false, SnapshotNow, 0,
NULL);
AssertState(scan != NULL);
***
*** 1220,1223
LockRelation(rel, lockstmt->mode);
heap_close(rel, NoLock);/* close rel, keep lock */
! }
--- 1224,1227
LockRelation(rel, lockstmt->mode);
heap_close(rel, NoLock);/* close rel, keep lock */
! }
I wish it would help you. If it´s necessary, drop me a line. Regards
Jose Luis Ozzano.
(P.D.: I attached the messaje in a file edited in LINUX. Maybe you have problems to
read the original text)
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: Large queries - again...
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 mensagem:9j8jce$ddo$[EMAIL PROTECTED] > 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 large, a NULL pointer is > returned from PQexec(). > I have tried using ZDE (http://www.zeoslib.org), which I helped > develop, and pgAccess. ZDE is based on the Zeos Database Objects library, > which provides full access to PostgreSQL to Borland Delphi and Borland C++ > Builder compilers. > Could anyone please try this query: > ftp://carcass.dhs.org/pub/test.zip on windows (using libpq) and confirm it > suceed ? This archive contains a test.sql source, which will create a dumb > table with a text filed and then try to insert in it a large data (>8192 > bytes) on it, and the libpq.dll I just compiled, for who want a fresh libpq > (it's virus free, don't worry... ). All my current PostgreSQL driver > implementation is depending on this. I'm sure the libpq will fail, unless > something very weird is happening in here... :) > Other friends have confirmed this behaviour. > I tried to look at the libpq sources to find out where's the error, > but I think it will take much less time to who develops it... > > Best Regards, > Steve Howe > > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: OID wraparound (was Re: [HACKERS] pg_depend)
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... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] BUG (fixed) in CREATE TABLE ADD CONSTRAINT...(v-7.0.2)
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: /home/projects/pgsql/cvsroot/pgsql/src/backend/commands/command.c,v 1.71
2000/04/12 17:14:57 momjian Exp $
in the code lines #1139 to #1150, when the function AlterTableAddConstraint() tries to
construct the vector of the trigger´s tgargs.
>From the position 4 and forward, it must collect the pairs of fk_attrs and pk_attrs
>(interleaved), but the current code put first all
fk_attrs and then all the pk_attrs, leading to an error.
I fixed the bug and tested the update and now it works well. I send you a "diff -c
command.c command.fixed.c" (with the diff :
GNU diffutils version 2.7) and the output is:
*** command.c Sun May 6 21:13:06 2001
--- command.fixed.c Mon Jul 9 19:58:21 2001
***
*** 19,24
--- 19,25
* manipulating code in the commands/ directory, should go
* someplace closer to the lib/catalog code.
*
+ *
*-
*/
#include "postgres.h"
***
*** 1138,1152
{
Ident *fk_at = lfirst(list);
! trig.tgargs[count++] = fk_at->name;
}
foreach(list, fkconstraint->pk_attrs)
{
Ident *pk_at = lfirst(list);
! trig.tgargs[count++] = pk_at->name;
}
! trig.tgnargs = count;
scan = heap_beginscan(rel, false, SnapshotNow, 0,
NULL);
AssertState(scan != NULL);
--- 1139,1156
{
Ident *fk_at = lfirst(list);
! trig.tgargs[count] = fk_at->name;
! count+=2;
}
+ count = 5;
foreach(list, fkconstraint->pk_attrs)
{
Ident *pk_at = lfirst(list);
! trig.tgargs[count] = pk_at->name;
! count+=2;
}
! trig.tgnargs = (count-1);
scan = heap_beginscan(rel, false, SnapshotNow, 0,
NULL);
AssertState(scan != NULL);
***
*** 1220,1223
LockRelation(rel, lockstmt->mode);
heap_close(rel, NoLock);/* close rel, keep lock */
! }
--- 1224,1227
LockRelation(rel, lockstmt->mode);
heap_close(rel, NoLock);/* close rel, keep lock */
! }
I wish it would help you. If it´s necessary, drop me a line. Regards
Jose Luis Ozzano.
(P.D.: I attached this same messaje, edited in LINUX, because yo may have trouble
reading it)
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: /home/projects/pgsql/cvsroot/pgsql/src/backend/commands/command.c,v 1.71 2000/04/12 17:14:57 momjian Exp $
in the code lines #1139 to #1150, when the function AlterTableAddConstraint() tries to construct the
vector of the trigger´s tgargs. From the position 4 and forward, it must collect the pairs of fk_attrs
and pk_attrs (interleaved), but the current code put first all fk_attrs and then all the pk_attrs,
leading to an error. I fixed the bug and tested the update and now it works well. I send you a
"diff -c command.c command.fixed.c" (with the diff : GNU diffutils version 2.7) and the output is:
*** command.c Sun May 6 21:13:06 2001
--- command.fixed.c Mon Jul 9 19:58:21 2001
***
*** 19,24
--- 19,25
* manipulating code in the commands/ directory, should go
* someplace closer to the lib/catalog code.
*
+ *
*-
*/
#include "postgres.h"
***
*** 1138,1152
{
Ident *fk_at = lfirst(list);
! trig.tgargs[count++] = fk_at->name;
}
foreach(list, fkconstraint->pk_attrs)
{
Ident *pk_at = lfirst(list);
! trig.tgargs[count++] = pk_at->name;
}
! trig.tgnargs = count;
scan = heap_begi
Re: [HACKERS] problem with creating/dropping tables and plpgsql ?
"\(::\) 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 don't coexist very well yet. (plpgsql tries to cache query plans, and at the moment there's no mechanism to let it flush obsolete plans when a table is deleted.) What you'll need to do is create a temp table that lasts for the whole session and is re-used by each successive call of the plpgsql function. You don't need to worry about dropping the temp table at session exit; that's what temp tables are for, after all, to go away automatically. So, just delete all its contents at entry or exit of the function, and you can re-use it each time through. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: hub.org out of disk space
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 the last 7.0.3 RPM will be removed, etc. A full RPMset across three or more platforms plus source takes a bit of space :-) ftp/pub/binary is only up to 353356 blocks, and /home/projects/pgsql is now down to 446308 free. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Large queries - again...
"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 like you are invoking an old (6.5 or before) libpq. Perhaps you should check around to see if there are multiple libpq.dll files on your system ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
AW: OID wraparound (was Re: [HACKERS] pg_depend)
> 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 update would do an update with a where restriction, that is not indexed. This would be darn slow, no ? How about instead selecting the primary key and one of the tid's (I never remember which, was it ctid ?) instead, so you can validate when a row changed between the select and the update ? Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Added TODO item
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 hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: OID wraparound (was Re: [HACKERS] pg_depend)
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 in cases where there is no oid on the table. If they ask for an OID in a table, make it the first column of a table. Also, if they have asked for oid's on the table, odds are they want SELECT * to show it. Also, how about a GUC option that controls whether tables are created with OID's by default. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] pg_dump(all) fails with "failed sanity chec, type with oid ..."
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 posts and suggested resolutions to the problems (which I haven't been able to use), and I think this is a bug that's been put on a TODO list. So, two questions: 1) Is a bugfix for pg_dump/pg_dumpall available, perhaps in the 7.1 version? 2) If the bugfix is available in 7.1, can I safely migrate data from 7.0.3 to 7.1, if i use the COPY command to export and import tables. Thanx. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Ability to create tables
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 the permission system for 7.2. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] C functions
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 some mysql stuff to postgres, and mysql has a function "concat" which will concatenate a number of fields. I have this coded for Postgres, but I can't get it registered. I used a few "create function" statements to cover the number of parameters I need, but this is really ugly. (Also, this will help with "decode()," an oraclesque function I use.) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: hub.org out of disk space
there, and I just cleared out about 500Meg+ of old garbage ... 1.2gig free
again ...
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.
>
> > /home/projects/pgsql partition at hub.org is down to zero free space...
> >
> > regards, tom lane
> >
> > ---(end of broadcast)---
> > TIP 2: you can get off all lists at once with the unregister command
> > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
> >
>
> Chris Bowlby,
> -
> Web Developer @ Hub.org.
> [EMAIL PROTECTED]
> www.hub.org
> 1-902-542-3657
> -
>
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: hub.org out of disk space
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... > > > > regards, tom lane > > > > ---(end of broadcast)--- > > TIP 2: you can get off all lists at once with the unregister command > > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > > > > Chris Bowlby, > - > Web Developer @ Hub.org. > [EMAIL PROTECTED] > www.hub.org > 1-902-542-3657 > - > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: hub.org out of disk space
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 broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > Chris Bowlby, - Web Developer @ Hub.org. [EMAIL PROTECTED] www.hub.org 1-902-542-3657 - ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: OID wraparound (was Re: pg_depend)
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 http://village.albourne.com Nicosia, Cyprus phone: +357-2-755750 "It is more complicated than you think" -- The Eighth Networking Truth from RFC 1925 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] problem with creating/dropping tables and plpgsql ?
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
--
1
(1 row)
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
--- schema --
CREATE FUNCTION doEverythingTemp(int,int) RETURNS int AS '
DECLARE
rrec RECORD;
userid int;
lookupid int;
rrating int;
ruser int;
BEGIN
userid := $1;
lookupid := $2;
FOR rrec IN SELECT webuser_id,rating FROM rating WHERE webuser_id!=userid AND
lookup_id=lookupid;
rrating:=rrec.rating;
ruser:=rrec.webuser_id;
INSERT INTO ttmptable SELECT lookup_id,rrating*rating FROM rating WHERE
webuser_id=ruser AND lookup_id!=lookupid;
END LOOP;
RETURN 1;
END;' LANGUAGE 'plpgsql'
Table "rating"
Attribute | Type | Modifier
-+-+--
webuser_id | integer | not null default '0'
category_id | integer | not null default '0'
lookup_id | integer | not null default '0'
rating | integer | not null default '0'
rating_id | integer | not null default nextval('"rating_rating_id_seq"'::text)
Indices: rating_category_id_idx,
rating_lookup_id_idx,
rating_rating_id_key,
rating_webuser_id_idx
I've tried regular tables, creating the table from within the function, and a few
other things.. no luck. Does anyone have ANY idea how I can either redesign this
query or make the create/drop thing work properly?
Thanks,
(::) Bob Ippolito
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[HACKERS] Large queries - again...
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 large, a NULL pointer is returned from PQexec(). I have tried using ZDE (http://www.zeoslib.org), which I helped develop, and pgAccess. ZDE is based on the Zeos Database Objects library, which provides full access to PostgreSQL to Borland Delphi and Borland C++ Builder compilers. Could anyone please try this query: ftp://carcass.dhs.org/pub/test.zip on windows (using libpq) and confirm it suceed ? This archive contains a test.sql source, which will create a dumb table with a text filed and then try to insert in it a large data (>8192 bytes) on it, and the libpq.dll I just compiled, for who want a fresh libpq (it's virus free, don't worry... ). All my current PostgreSQL driver implementation is depending on this. I'm sure the libpq will fail, unless something very weird is happening in here... :) Other friends have confirmed this behaviour. I tried to look at the libpq sources to find out where's the error, but I think it will take much less time to who develops it... Best Regards, Steve Howe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
