[HACKERS] AW: [HACKERS] WAL documentation
Using pg_control to get checkpoint position speed up things but to handle possible pg_control corruption we obviously should implement reading existent log segments (from the last one - newest - to oldest) to get last checkpoint. I think this would be *very* important :-) Andreas
Re: [HACKERS] Open 7.1 items
Quoting Bruce Momjian [EMAIL PROTECTED]:
I have trickled the emails as I reviewed them, asking for comments. It
was not one big email.
I haven't seen them either, although my Inbox is big again, and I'm filtering
out mails by their subject line, so it's possible I've missed them.
I'm slowly working my way through JDBC, but it's all hinging on getting my
linux box back online. It's powered up, but not talking to the network :-(
Should be sorted by Saturday morning...
Peter
haven't seen it posted to hackers, or, if I did, I didn't clue into it
...
and just checked to see if maybe it was waiting for approval due to
size,
and nothing in the queue ...
posting it here is easier to respond to ...
On Wed, 24 Jan 2001, Bruce Momjian wrote:
I have about 20 open 7.1 items that I need to get resolved before I
can
start getting the doc TODO list started. The issues relate to
JDBC,
ODBC, and lots of other stuff that need to be settled before we can
finalize 7.1.
They can not be easily summarized in one line. You really have to
see
the whole email to understand the issues.
How do people want to do this? I can post them to hackers, or put
them
on my web site. I posted them to hackers during the past few days,
but
many went unanswered. These are all relatively new from the past
few
months.
--
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
Marc G. Fournier ICQ#7615664 IRC Nick:
Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary:
scrappy@{freebsd|postgresql}.org
--
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
--
Peter Mount [EMAIL PROTECTED]
PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/
RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
Re: [HACKERS] Open 7.1 items
Bruce Momjian [EMAIL PROTECTED] writes: Here are my open 7.1 items. Thanks for shrinking the list so far. SELECT cash_out(1) crashes all backends This isn't a "must fix for 7.1", any more than it was for 7.0, 6.5, or any other release back to the beginning of time. It's always been possible to crash the backend by passing an incompatible argument to a type input or output function. The type-checking system cannot detect the error because these functions are (mostly) declared to take "any" input type (zero entry in proargtypes[]). The only clean way to fix this is to declare I/O functions honestly. That will require (a) a type-system representation for "C string" and (b) a solution to the circularity issue for user-defined types. If the I/O functions have to be declared first, how can they refer to the type? Quite aside from the time involved, this will require an initdb. It's a bit late in the cycle for that. regards, tom lane
Re: [HACKERS] beta3 Solaris 7 (SPARC) port report [ Was: Looking for . . . ]
On Thu, Jan 25, 2001 at 12:42:45AM +0100, Peter Eisentraut wrote: Frank Joerdens writes: [randomly varying set of regression tests fail] Running the tests on my Linux box gives no failed tests. Must I assume that those failed tests indicate some issue that is is detrimental to the proper functioning of the server on this Solaris installation? Do you want the regression.diffs? Could you go into src/test/regress/pg_regress.sh and edit around line 162 #case $host_platform in #*-*-qnx* | *beos*) unix_sockets=no;; #*) #unix_sockets=yes;; #esac (i.e., ensure that unix_sockets is set to 'no'), and rerun 'make check'. I just did that and ran make check 4 times. 3 times went completely smoothly, once I had random fail. This is the same behaviour that I saw when running make installcheck (76 successful most of the time, sometimes you get 75 out of 76 with random being the one that fails). I have experienced before that Unix sockets will cause random connection abortions on Solaris [ . . . ] Isn't that _really_ bad? Random connection abortions when going over Unix sockets?? My app does _all_ the connecting over Unix sockets?! I also tried using the Sun compiler, which didn't work at all. details on "didn't work" requested... -- begin details -- $ export CC=CC $ echo $CC CC $ ./configure creating cache ./config.cache checking host system type... sparc-sun-solaris2.7 checking which template to use... solaris checking whether to build with locale support... no checking whether to build with recode support... no checking whether to build with multibyte character support... no checking whether to build with Unicode conversion support... no checking for default port number... 5432 checking for default soft limit on number of connections... 32 checking for gcc... CC checking whether the C compiler (CC ) works... yes checking whether the C compiler (CC ) is a cross-compiler... no checking whether we are using GNU C... no checking whether CC accepts -g... yes using CFLAGS=-v checking whether the C compiler (CC -Xa -v ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. -- end details -- Cheers, Frank
[HACKERS] Re: PHP - Postgres large object functions
El Mi 24 Ene 2001 17:56, Ned Lilly escribi: Adam, FYI, according to Rasmus Lerdorf, your patches have been committed. From the changelog: 2001-01-18 Derick Rethans [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * ext/pgsql/pgsql.c ext/pgsql/php_pgsql.h: - Added the pg_lolseek function, which allows for arbitrary seeking within a large object, and the pg_lotell call, which can be used to find the current file offset for a large object (Submitted by: Adam Haberlach [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]). - Added the pg_lolseek and pg_lotell functions I've had headaches trying to understand how PHP works with postgres large objects. Is there some kind of "understandable" docs on this behave? Saludos... :-) -- System Administration: It's a dirty job, but someone told I had to do it. - Martn Marqus email: [EMAIL PROTECTED] Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -
[HACKERS] email address change
My email address has been changed. From now on, please write to [EMAIL PROTECTED] The "tip" user at the same host no longer exists. Sorry for the inconvenience if you tried to send a message to the "tip" user this week. Have a nice day, :^) Zoltan -- Kov\'acs, Zolt\'an [EMAIL PROTECTED] http://www.math.u-szeged.hu/~kovzol ftp://pc10.radnoti-szeged.sulinet.hu/home/kovacsz
Re: [HACKERS] beta3 Solaris 7 (SPARC) port report [ Was: Lookingfor . . . ]
Worked fine for me... % uname -a SunOS lancelot 5.7 Generic_106541-14 sun4m sparc SUNW,SPARCstation-4 % ls -l -rw-r--r-- 1 bpalmer staff32860160 Jan 23 16:45 postgresql-snapshot.tar ... ... ... transactions ... ok random ... failed (ignored) portals ... ok ... ... ... == 75 of 76 tests passed, 1 failed test(s) ignored. == On Thu, 25 Jan 2001, Peter Eisentraut wrote: Frank Joerdens writes: [randomly varying set of regression tests fail] Running the tests on my Linux box gives no failed tests. Must I assume that those failed tests indicate some issue that is is detrimental to the proper functioning of the server on this Solaris installation? Do you want the regression.diffs? Could you go into src/test/regress/pg_regress.sh and edit around line 162 #case $host_platform in #*-*-qnx* | *beos*) unix_sockets=no;; #*) #unix_sockets=yes;; #esac (i.e., ensure that unix_sockets is set to 'no'), and rerun 'make check'. I have experienced before that Unix sockets will cause random connection abortions on Solaris, which will cause the regression tests to fail arbitrarily. I also tried using the Sun compiler, which didn't work at all. details on "didn't work" requested... now I get scary stuff like: --- begin scary stuff --- test int2 ... ERROR: pg_atoi: error in "34.5": can't parse ".5" ERROR: pg_atoi: error reading "10": Result too large ERROR: pg_atoi: error in "asdf": can't parse "asdf" This is normal. The regression tests sometimes involve intentional invalid input. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ b. palmer, [EMAIL PROTECTED] pgp: www.crimelabs.net/bpalmer.pgp5
Re: [HACKERS] Re: AW: Re: MySQL and BerkleyDB (fwd)
yup :-) Maybe this could even be raised to the SQL level, so applications could use this ? I have not seen this elsewhere, but why actually not ? Yes please :-) if someone is to code this quicker than me (I suppose so, since I have other projects to deal with concurrently). -- Tout n'y est pas parfait, mais on y honore certainement les jardiniers Dominique Quatravaux [EMAIL PROTECTED]
[HACKERS] Re: Re: MySQL has transactions
When Postgresql 6.5 came out it, it was VERY MUCH better ( many many thanks to the developers and all involved). And I'm waiting for a solid 7.1 to fix that 8KB issue. Technically.. = BLCKSZ (can be up to 32k) I've been using PostgreSQL with a 32k BLCKSZ since 7.0 (on a productions server) and haven't had a problem one.. -Mitch
Re: [HACKERS] Open 7.1 items
Bruce Momjian writes: FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" You're certainly not going to want to fix this now after having stared at it for a year? It's not trivial. Usernames limited in length Yeah, they are. ;-) If this is referring to pg_passwd, I just had a closer look and it's really a desaster. Both password and username as well as line length and file length (in lines) have arbitrary limits, sometimes not even consistent ones. To fix this to a point where one is confident that everything works one essentially would have to rewrite the whole thing. Does pg_dump preserve COMMENTs? Sure Fix ipcclean on Linux Consider it done. Merge global and template BKI files? Not this release. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] new version of contrib-intarray
Mark, we prepared new version of contrib-intarray - index support for 1-D integer arrays using GiST. Changes: - Improved regression test - Current implementation provides index support for one-dimensional array of int4's - gist__int_ops, suitable for small and medium size of arrays, and gist__intbig_ops for indexing large arrays (we use superimposed signature with length of 4096 bits to represent sets, see Sven Helmer,1997). Archive is available from http://www.sai.msu.su/~megera/postgres/gist/code/7.1/contrib-intarray.tar.gz Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
RE: [HACKERS] Permissions on CHECKPOINT
Mikheev, Vadim writes:
Yes, there should be permission checking - I'll add it later (in 7.1)
if no one else.
Should be simple enough. Is this okay:
Index: utility.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/tcop/utility.c,v
retrieving revision 1.105
diff -c -r1.105 utility.c
*** utility.c 2001/01/05 06:34:20 1.105
--- utility.c 2001/01/25 16:40:40
***
*** 18,23
--- 18,24
#include "access/heapam.h"
#include "catalog/catalog.h"
+ #include "catalog/pg_shadow.h"
#include "commands/async.h"
#include "commands/cluster.h"
#include "commands/command.h"
***
*** 851,856
--- 852,859
{
set_ps_display(commandTag = "CHECKPOINT");
+ if (!superuser())
+ elog(ERROR, "permission denied");
CreateCheckPoint(false);
}
break;
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] postgresql.conf and postgres options
Bruce Momjian writes:
I have added all possible config options to postgresql.conf.sample.
It was actually fully intentional that there was *no* list of all possible
config options in the sample file, because
1) Who's going to maintain this?
2) People should read the documentation before messing with options.
(" is not the correct string delimiter either.)
I have bad experiences with sample config files. The first thing I
usually do is delete them and dig up the documentation.
Do other people have comments on this issue?
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] RPM: Contrib request.
It has been requested that I ship prebuilt contrib items in the 7.1 RPMset. Currently, the source code of the whole contrib tree is being shipped in the main RPM as documentation, but only autoinc and refint are being prebuilt (as part of the -test subpackage). I have had three different types of request on this: 1.) The whole contrib tree prebuilt; 2.) Select parts of the contrib tree prebuilt (geospatial stuff for the most part); 3.) pg_dumplo. Now, I see a couple of different ways I can go about doing this -- I can build a large 'postgresql-contrib' RPM (which would also eliminate the source of the contrib tree in the documentation -- possibly) containing the _whole_ tree, prebuilt (possibly in /usr/lib/pgsql (or postgresql -- I'm not at all settled on the subdir naming scheme) -- OR, I can build individual RPMs for each contrib element. But, in the instance of pg_dumplo -- can I get some ideas on it? Should it be shipped as a separate package, or in the -server subpackage, or?? I am open to suggestions. If PORTS is a more appropriate list to post this, I will do that as well. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] beta3 Solaris 7 (SPARC) port report [ Was: Looking for . . . ]
On Thu, Jan 25, 2001 at 05:12:02PM +0100, Peter Eisentraut wrote: Frank Joerdens writes: I have experienced before that Unix sockets will cause random connection abortions on Solaris [ . . . ] Isn't that _really_ bad? Random connection abortions when going over Unix sockets?? My app does _all_ the connecting over Unix sockets?! That's bad, for sure. Maybe you can check for odd conditions surrounding the /tmp directory, like is it on NFS, permission problems, mount options. I don't have neither root nor physical access to this machine, hence my options are kinda limited. However, the sysadmin told me that most of the storage space on this box is mounted over a fibre channel (I only have a very hazy notion of what exactly that might be) from a "storage server" which is allegedly as fast as a local SCSI disk. Or is there something odd in the kernel configuration? If I'm counting correctly this is the third independent report of this problem, which is scary. I'll question the sysadmin about that. But why does make installcheck work? Because it goes over TCP/IP sockets by default? I also tried using the Sun compiler, which didn't work at all. details on "didn't work" requested... -- begin details -- $ export CC=CC Using a C++ compiler to compile C code won't work. You probably meant CC=cc and CXX=CC. When I do that, make fails with the following error (after giving lots of warnings): "pg_dump.c", line 1063: warning: Function has no return statement : main cc -Xa -v -I../../../src/include -I../../../src/interfaces/libpq -c -o common.o common.c cc -Xa -v -I../../../src/include -I../../../src/interfaces/libpq -c -o pg_backup_archiver.o pg_backup_archiver.c cc -Xa -v -I../../../src/include -I../../../src/interfaces/libpq -c -o pg_backup_db.o pg_backup_db.c cc -Xa -v -I../../../src/include -I../../../src/interfaces/libpq -c -o pg_backup_custom.o pg_backup_custom.c cc -Xa -v -I../../../src/include -I../../../src/interfaces/libpq -c -o pg_backup_files.o pg_backup_files.c cc -Xa -v -I../../../src/include -I../../../src/interfaces/libpq -c -o pg_backup_null.o pg_backup_null.c "pg_backup_null.c", line 90: controlling expressions must have scalar type cc: acomp failed for pg_backup_null.c make[3]: *** [pg_backup_null.o] Error 2 make[3]: Leaving directory `/usr/users/fjoerde/postgres/postgresql-7.1beta3_test/src/bin/pg_dump' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/users/fjoerde/postgres/postgresql-7.1beta3_test/src/bin' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/users/fjoerde/postgres/postgresql-7.1beta3_test/src' make: *** [all] Error 2 Regards, Frank
Re: [HACKERS] beta3 Solaris 7 (SPARC) port report [ Was: Looking for . . . ]
On Thu, Jan 25, 2001 at 05:12:02PM +0100, Peter Eisentraut wrote: Frank Joerdens writes: I have experienced before that Unix sockets will cause random connection abortions on Solaris [ . . . ] Isn't that _really_ bad? Random connection abortions when going over Unix sockets?? My app does _all_ the connecting over Unix sockets?! That's bad, for sure. Maybe you can check for odd conditions surrounding the /tmp directory, like is it on NFS, permission problems, mount options. I just typed $ mount and I get /tmp on swap read/write/setuid on Mon Jan 22 16:39:32 2001 for the /tmp directory, which looks distinctly odd to me. What kind of device is swap (I know what swap is normally but I didn't know you could mount stuff there . . . )?? Regards, Frank
Re: [HACKERS] beta3 Solaris 7 (SPARC) port report [ Was: Lookingfor . . . ]
Frank Joerdens writes: That's bad, for sure. Maybe you can check for odd conditions surrounding the /tmp directory, like is it on NFS, permission problems, mount options. I don't have neither root nor physical access to this machine, hence my options are kinda limited. Entering 'mount' should tell you. I'll question the sysadmin about that. But why does make installcheck work? Because it goes over TCP/IP sockets by default? No. Presumably because it does not run more than one test in parallel. "pg_backup_null.c", line 90: controlling expressions must have scalar type cc: acomp failed for pg_backup_null.c Line 90 has a comment in my copy. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] BETWEEN patch
At 1/24/2001 10:19 AM, Tom Lane wrote: Thomas Swan [EMAIL PROTECTED] writes: A patch to gram.y in src/backend/parser Provides for the SQL99 expected behavior of select * from foo where fo_num between 1 and 5 yields the same result as select * from foo where fo_num between 5 and 1 This is NOT correct under either SQL92 or SQL99. Read the spec again. regards, tom lane After sending it... I realized that it was not correct either. So, I'm back to figuring how to do it... so, um, ignore the previous patch... Thanks..
[HACKERS] pg_dump issues
Could we add a flag to remove the postgres specific information from a
pg_dump?
--
UPDATE "pg_class" SET "reltriggers" = 0 WHERE "relname" ~*
'market_type';
BEGIN TRANSACTION;
CREATE TEMP TABLE "tr" ("tmp_relname" name, "tmp_reltriggers"
smallint);
INSERT INTO "tr" SELECT C."relname", count(T."oid") FROM "pg_class" C,
"pg_trigger" T WHERE C."oid" = T."tgrelid" AND C."relname" ~*
'market_type' GROUP BY 1;
UPDATE "pg_class" SET "reltriggers" = TMP."tmp_reltriggers" FROM "tr"
TMP WHERE "pg_class"."relname" = TMP."tmp_relname";
DROP TABLE "tr";
COMMIT TRANSACTION;
--
These make importing into other database systems rather difficult.
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what really happened.
BEGIN:VCARD
VERSION:2.1
N:Taylor;Rod;B
FN:Taylor, Rod B
ORG:BarChord Entertainment Inc.;System Operation and Development
TITLE:Chief Technical Officer
ADR;WORK:;;;Toronto;Ontario;;Canada
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Toronto, Ontario=0D=0ACanada
X-WAB-GENDER:2
URL:
URL:http://www.barchord.com
BDAY:19790401
EMAIL;INTERNET:[EMAIL PROTECTED]
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
EMAIL;INTERNET:[EMAIL PROTECTED]
REV:20010124T194835Z
END:VCARD
Re: [HACKERS] RPM: Contrib request.
Now that pg_dump pg_restore can handle large objects, the only need for pg_dumplo is for migrating large objects from prior versions. I personally cannot see it being used on a day to day basis, but I'm looking at it from a narrow perspective. If it is a separate package, it can easily be removed from a production system after data has been migrated. On the other hand, you never know when someone may need to restore large objects from a pre 7.1 backup. I think the cleanest way to provide the contrib programs is to build a postgresql-contrib with _everything_ in it. Those people who need a specific binary will be able to get it from /usr/lib/pgsql (or wherever) and the distiction between core and contrib programs will not be fuzzy. Lamar Owen wrote: It has been requested that I ship prebuilt contrib items in the 7.1 RPMset. Currently, the source code of the whole contrib tree is being shipped in the main RPM as documentation, but only autoinc and refint are being prebuilt (as part of the -test subpackage). I have had three different types of request on this: 1.) The whole contrib tree prebuilt; 2.) Select parts of the contrib tree prebuilt (geospatial stuff for the most part); 3.) pg_dumplo. Now, I see a couple of different ways I can go about doing this -- I can build a large 'postgresql-contrib' RPM (which would also eliminate the source of the contrib tree in the documentation -- possibly) containing the _whole_ tree, prebuilt (possibly in /usr/lib/pgsql (or postgresql -- I'm not at all settled on the subdir naming scheme) -- OR, I can build individual RPMs for each contrib element. But, in the instance of pg_dumplo -- can I get some ideas on it? Should it be shipped as a separate package, or in the -server subpackage, or?? I am open to suggestions. If PORTS is a more appropriate list to post this, I will do that as well. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 -- --- Randy HallGreat Bridge, LLC Sr. Knowledge Engineer253 Monticello Avenue Red Hat Certified EngineerNorfolk, VA 23410
Re: [HACKERS] beta3 Solaris 7 (SPARC) port report [ Was: Looking for . . . ]
On Thu, Jan 25, 2001 at 12:04:40PM -0800, Ian Lance Taylor wrote: [ . . . ] for the /tmp directory, which looks distinctly odd to me. What kind of device is swap (I know what swap is normally but I didn't know you could mount stuff there . . . )?? That is a tmpfs file system which uses swap space for /tmp storage. Both swap usage and /tmp compete for the same partition on the disk. If you have a lot of swapping programs, you don't get to put much in /tmp. If you have a lot of files in /tmp, you don't get to run many programs. As far as I can recall, this is a Sun specific thing. It's a reasonable idea on a stable system. It's a pretty crummy idea on a development system, or one with unpredictable loads. My experience is that either something goes crazy and fills up /tmp and then you can't run anything else and you have to reboot, or something goes crazy and fills up swap and then you can't write any /tmp files and daemon processes start to silently die and you have to reboot. Very peculiar, or crummy, indeed. This is system is not used by anyone else besides myself at the moment (cuz it's just being built up), as far a I can tell, and is ludicrously overpowered (3 CPUs, 768 MB RAM) for the mundane uses I am subjecting it to (installing and testing Postgresql). Regards, Frank
[HACKERS] backend closed --- I'd like to write a conversion function
I've got "backend closed" errors --- they seem to be indeterministic. I am using 7.0.2 but I tried this with 7.1beta3 as well and the error was similar (but not completely same). I wrote a char* - char* conversion function. Now I would use textout() and textin() to make it possible using my converter for varchars. I use them, OK. But sometimes calling pfree() closes my backend. I haven't tried this with the new Datum-based builtin converter functions with 7.1 yet because we are heavily standing on the base of 7.0.2. What I exactly did: 1.2. 3. 4. text* textout--- char* ---konvertal_c--- char* textin-- text* In 7.0.2 if I use malloc() I only can release the 3. variable, if I would do a free() for the 2. variable, I get the "backend closed" error at once. OK, I realized that a new way is suggested for doing this: palloc() and pfree(). OK, it works: no "backend closed" error if I use them, or at least not at once. But I also get these type of errors, especially for bigger queries or if I put my text* - text* (i.e. varchar - varchar) conversion machine into an ORDER BY clause. In 7.1beta3 I also got the next message: Backend message type 0x44 arrived while idle pqReadData() -- backend closed the channel unexpectedly. This probably means the backend terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. The differences between the 7.0.2 and 7.1beta3 behaviour, that 7.1beta3 doesn't like pfree() calls. What to do? Please help if you can. Regards, Zoltan -- Kov\'acs, Zolt\'an [EMAIL PROTECTED] http://www.math.u-szeged.hu/~kovzol ftp://pc10.radnoti-szeged.sulinet.hu/home/kovacsz
Re: [HACKERS] beta3 Solaris 7 (SPARC) port report
On Thu, Jan 25, 2001 at 09:47:16PM +0100, Frank Joerdens wrote: On Thu, Jan 25, 2001 at 12:04:40PM -0800, Ian Lance Taylor wrote: [ . . . ] for the /tmp directory, which looks distinctly odd to me. What kind of device is swap (I know what swap is normally but I didn't know you could mount stuff there . . . )?? That is a tmpfs file system which uses swap space for /tmp storage. Both swap usage and /tmp compete for the same partition on the disk. If you have a lot of swapping programs, you don't get to put much in /tmp. If you have a lot of files in /tmp, you don't get to run many programs. As far as I can recall, this is a Sun specific thing. It's a reasonable idea on a stable system. It's a pretty crummy idea on a development system, or one with unpredictable loads. My experience is that either something goes crazy and fills up /tmp and then you can't run anything else and you have to reboot, or something goes crazy and fills up swap and then you can't write any /tmp files and daemon processes start to silently die and you have to reboot. Very peculiar, or crummy, indeed. This is system is not used by anyone else besides myself at the moment (cuz it's just being built up), as far a I can tell, and is ludicrously overpowered (3 CPUs, 768 MB RAM) for the mundane uses I am subjecting it to (installing and testing Postgresql). I doubt you can blame any problems on tmpfs, here. tmpfs has been in Solarix for many years, and has had plenty of time to stabilize. With 768M of RAM and running only PG you not using any swap space at all, and unix sockets don't use any appreciable space either, so the conflicts Ian describes are impossible in your case. Nathan Myers [EMAIL PROTECTED]
Re: [HACKERS] backend closed --- I'd like to write a conversionfunction
You probably should be getting core files from this. Have you tried recompiling with debugging and asserts on and then looking through the core file, that might give some more information as to the details. On Thu, 25 Jan 2001, Kovacs Zoltan wrote: I've got "backend closed" errors --- they seem to be indeterministic. I am using 7.0.2 but I tried this with 7.1beta3 as well and the error was similar (but not completely same). [...] What to do? Please help if you can.
[HACKERS] Talking about Solaris 7
I have a problem with the compilation of Postgres on Solaris with ssl support. The error I get is this when executing make: gcc -g -Wall -Wmissing-prototypes -Wmissing-declarations -I/usr/local/include -I/usr/local/ssl//include -I../../../src/include -c nodeTidscan.c -o nodeTidscan.ogcc -g -Wall -Wmissing-prototypes -Wmissing-declarations -I/usr/local/include -I/usr/local/ssl//include -I../../../src/include -c spi.c -o spi.o /usr/ccs/bin/ld -r -o SUBSYS.o execAmi.o execFlatten.o execJunk.o execMain.o execProcnode.o execQual.o execScan.o execTuples.o execUtils.o functions.o nodeAppend.o nodeAgg.o nodeHash.o nodeHashjoin.o nodeIndexscan.o nodeMaterial.o nodeMergejoin.o nodeNestloop.o nodeResult.o nodeSeqscan.o nodeSetOp.o nodeSort.o nodeUnique.o nodeLimit.o nodeGroup.o nodeSubplan.o nodeSubqueryscan.o nodeTidscan.o spi.o make[3]: Leaving directory `/space/pruebas/postgresql-7.1beta1/src/backend/executor' /usr/local/bin/make -C lib all make[3]: Entering directory `/space/pruebas/postgresql-7.1beta1/src/backend/lib' gcc -g -Wall -Wmissing-prototypes -Wmissing-declarations -I/usr/local/include -I/usr/local/ssl//include -I../../../src/include -c bit.c -o bit.o gcc -g -Wall -Wmissing-prototypes -Wmissing-declarations -I/usr/local/include -I/usr/local/ssl//include -I../../../src/include -c hasht.c -o hasht.o gcc -g -Wall -Wmissing-prototypes -Wmissing-declarations -I/usr/local/include -I/usr/local/ssl//include -I../../../src/include -c lispsort.c -o lispsort.o gcc -g -Wall -Wmissing-prototypes -Wmissing-declarations -I/usr/local/include -I/usr/local/ssl//include -I../../../src/include -c stringinfo.c -o stringinfo.o gcc -g -Wall -Wmissing-prototypes -Wmissing-declarations -I/usr/local/include -I/usr/local/ssl//include -I../../../src/include -c dllist.c -o dllist.o /usr/ccs/bin/ld -r -o SUBSYS.o bit.o hasht.o lispsort.o stringinfo.o dllist.o make[3]: Leaving directory `/space/pruebas/postgresql-7.1beta1/src/backend/lib' /usr/local/bin/make -C libpq all make[3]: Entering directory `/space/pruebas/postgresql-7.1beta1/src/backend/libpq' gcc -g -Wall -Wmissing-prototypes -Wmissing-declarations -I/usr/local/include -I/usr/local/ssl//include -I../../../src/include -c be-fsstubs.c -o be-fsstubs.o gcc -g -Wall -Wmissing-prototypes -Wmissing-declarations -I/usr/local/include -I/usr/local/ssl//include -I../../../src/include -c auth.c -o auth.o gcc -g -Wall -Wmissing-prototypes -Wmissing-declarations -I/usr/local/include -I/usr/local/ssl//include -I../../../src/include -c crypt.c -o crypt.o In file included from crypt.c:27: /usr/include/crypt.h:23: conflicting types for `des_encrypt' /usr/local/ssl/include/openssl/des.h:150: previous declaration of `des_encrypt' make[3]: *** [crypt.o] Error 1 make[3]: Leaving directory `/space/pruebas/postgresql-7.1beta1/src/backend/libpq' make[2]: *** [libpq-recursive] Error 2 make[2]: Leaving directory `/space/pruebas/postgresql-7.1beta1/src/backend' make[1]: *** [all] Error 2 make[1]: Leaving directory `/space/pruebas/postgresql-7.1beta1/src' make: *** [all] Error 2 *** Error code 2 make: Fatal error: Command failed for target `all' Any extra code you may want, just ask. -- System Administration: It's a dirty job, but someone told I had to do it. - Martn Marqus email: [EMAIL PROTECTED] Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -
Re: [HACKERS] Open 7.1 items
Fix for pg_dump of bad system tables
Ok. I have made patches for fixing some of pg_dump problems(see
attached patches). The patches address the problem with user defined
functions, operators and aggregates. Could someone please review and
commit them if they look ok? (I'm now in US and have only very
expensive internet connection through an international phone call to
Japan in a hotel! Also I'm not quite sure "#arg" (stringification) is
portable enough in all platforms.) Or I could commit after going back
to Japan planned on Feb 2 if that's not too late.
However I have not address what Tom Lane said yet(actually I do not
understand what he says).
The other flavor of problems that pg_dump
has in this area are in doing inner joins across system catalogs ...
regards, tom lane
Index: common.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/bin/pg_dump/common.c,v
retrieving revision 1.49
diff -c -r1.49 common.c
*** common.c2001/01/12 15:41:29 1.49
--- common.c2001/01/21 01:38:48
***
*** 86,95
}
}
! /* should never get here */
! fprintf(stderr, "failed sanity check, type with oid %s was not found\n",
! oid);
! exit(2);
}
/*
--- 86,93
}
}
! /* no suitable type name was found */
! return(NULL);
}
/*
***
*** 114,120
/* should never get here */
fprintf(stderr, "failed sanity check, opr with oid %s was not found\n",
oid);
! exit(2);
}
--- 112,120
/* should never get here */
fprintf(stderr, "failed sanity check, opr with oid %s was not found\n",
oid);
!
! /* no suitable operator name was found */
! return(NULL);
}
*** pg_dump.c.orig Fri Jan 26 06:56:09 2001
--- pg_dump.c Fri Jan 26 06:35:26 2001
***
*** 2928,2933
--- 2928,2942
char *elemType;
elemType = findTypeByOid(tinfo, numTypes, tinfo[i].typelem,
zeroAsOpaque);
+ if (elemType == NULL)
+ {
+ fprintf(stderr, "Notice: type for oid %s is not
+dumped.\n",
+ tinfo[i].typelem);
+ resetPQExpBuffer(q);
+ resetPQExpBuffer(delq);
+ continue;
+ }
+
appendPQExpBuffer(q, ", element = %s, delimiter = ", elemType);
formatStringLiteral(q, tinfo[i].typdelim);
}
***
*** 3086,3091
--- 3095,3101
char*listSep;
char*listSepComma = ",";
char*listSepNone = "";
+ char*rettypename;
if (finfo[i].dumped)
return;
***
*** 3147,3152
--- 3157,3177
char*typname;
typname = findTypeByOid(tinfo, numTypes, finfo[i].argtypes[j],
zeroAsOpaque);
+ if (typname == NULL)
+ {
+ fprintf(stderr, "Notice: function \"%s\" is not dumped.\n",
+ finfo[i].proname);
+
+ fprintf(stderr, "Reason: the %d th argument type name (oid %s)
+not found.\n",
+ j, finfo[i].argtypes[j]);
+ resetPQExpBuffer(q);
+ resetPQExpBuffer(fn);
+ resetPQExpBuffer(delqry);
+ resetPQExpBuffer(fnlist);
+ resetPQExpBuffer(asPart);
+ return;
+ }
+
appendPQExpBuffer(fn, "%s%s",
(j 0) ? "," : "",
typname);
***
*** 3159,3169
resetPQExpBuffer(delqry);
appendPQExpBuffer(delqry, "DROP FUNCTION %s;\n", fn-data );
resetPQExpBuffer(q);
appendPQExpBuffer(q, "CREATE FUNCTION %s ", fn-data );
appendPQExpBuffer(q, "RETURNS %s%s %s LANGUAGE ",
(finfo[i].retset) ? "SETOF " : "",
! findTypeByOid(tinfo, numTypes,
finfo[i].prorettype, zeroAsOpaque),
asPart-data);
formatStringLiteral(q, func_lang);
--- 3184,3211
resetPQExpBuffer(delqry);
appendPQExpBuffer(delqry, "DROP FUNCTION %s;\n", fn-data );
+ rettypename = findTypeByOid(tinfo, numTypes, finfo[i].prorettype,
+zeroAsOpaque);
+
+ if (rettypename == NULL)
+ {
+
Re: [HACKERS] RPM: Contrib request.
Randy Hall wrote: I think the cleanest way to provide the contrib programs is to build a postgresql-contrib with _everything_ in it. Those people who need a specific binary will be able to get it from /usr/lib/pgsql (or wherever) and the distiction between core and contrib programs will not be fuzzy. This is what I do for the Debian release. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "My little children, let us not love in word, neither in tongue; but in deed and in truth." I John 3:18
Re: [HACKERS] RPM: Contrib request.
On Thu, 25 Jan 2001, Lamar Owen wrote: But, in the instance of pg_dumplo -- can I get some ideas on it? Should it be shipped as a separate package, or in the -server subpackage, or?? ..ignore it. Not needful for 7.1, but can be interesting for 7.1 (old DB users can found it directly on source tree, ftp ..etc.) Karel
Re: [HACKERS] RPM: Contrib request.
Oliver Elphick wrote: Randy Hall wrote: I think the cleanest way to provide the contrib programs is to build a postgresql-contrib with _everything_ in it. Those people who need a specific binary will be able to get it from /usr/lib/pgsql (or wherever) and the distiction between core and contrib programs will not be fuzzy. This is what I do for the Debian release. Precedent set; precedent followed. I'll be hopefully packaging the _entire_ contrib tree :-) for beta 4, over the weekend. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] pg_dump issues
At 14:48 24/01/01 -0500, Rod Taylor wrote: Could we add a flag to remove the postgres specific information from a pg_dump? It's easy enough to do, but removing all PG-specific information is probably undesirable since, eg, pg_dump does not dump foreign key constraints in a standard way (it just dumps the rules). pg_dump also issues '\connect' statements, and will dump user-defined types, rules and functions that will probably not conform to the SQL standard. Over time I would like to see the output of pg_dump become as standard as possible - but in the mean time, would people see any value in a flag to do any of the following: (a) disable modifications to system tables (eg. turning off triggers and constraints) (b) just disable code which turns off the triggers? Or something else... (c) something else I can actually see value in (b) since people may want to load a single table *and* have triggers operating. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] beta3 Solaris 7 (SPARC) port report [ Was: Looking for . . . ]
Frank Joerdens [EMAIL PROTECTED] writes: I just did that and ran make check 4 times. 3 times went completely smoothly, once I had random fail. This is the same behaviour that I saw when running make installcheck (76 successful most of the time, sometimes you get 75 out of 76 with random being the one that fails). Er, you do realize that the random test is *supposed* to fail every so often? (Else it'd not be random...) See the pages on interpreting regression test results in the admin guide. What troubles me is the nonrepeatable failures you saw on other tests. As Peter says, if "make installcheck" (serial tests) is perfectly solid and "make check" (parallel tests) is not, that suggests some kind of interprocess locking problem. But we haven't heard about any such issue on Solaris. regards, tom lane
Re: [HACKERS] Open 7.1 items
Peter Eisentraut wrote: Bruce Momjian writes: FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" You're certainly not going to want to fix this now after having stared at it for a year? It's not trivial. What does this item mean ? Usernames limited in length Yeah, they are. ;-) If this is referring to pg_passwd, I just had a closer look and it's really a desaster. Both password and username as well as line length and file length (in lines) have arbitrary limits, sometimes not even consistent ones. To fix this to a point where one is confident that everything works one essentially would have to rewrite the whole thing. Does pg_dump preserve COMMENTs? Sure Fix ipcclean on Linux Consider it done. Merge global and template BKI files? Not this release. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] BETWEEN patch
Thomas Swan [EMAIL PROTECTED] writes: select * from foo where fo_num between 1 and 5 yields the same result as select * from foo where fo_num between 5 and 1 This is NOT correct under either SQL92 or SQL99. Read the spec again. After sending it... I realized that it was not correct either. So, I'm back to figuring how to do it... so, um, ignore the previous patch... Someone (Easter, IIRC) already submitted a patch to support the SQL99 SYMMETRIC BETWEEN option. I think we're sitting on it till 7.2, on the grounds of "no new features in beta". Check the list archives for the last few weeks if you need it now. regards, tom lane
Re: [HACKERS] Open 7.1 items
Sorry for my previous incomplete posting. Peter Eisentraut wrote: Bruce Momjian writes: FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" You're certainly not going to want to fix this now after having stared at it for a year? It's not trivial. What does this item mean ? Is it the following ? begin; insert into pk (id) values (1); update(delete from) pk where id=1; ERROR: triggered data change violation on relation pk" If so, isn't it a simple bug ? Regards, Hiroshi Inoue
Re: [HACKERS] RPM: Contrib request.
Lamar Owen [EMAIL PROTECTED] writes: I think the cleanest way to provide the contrib programs is to build a postgresql-contrib with _everything_ in it. This is what I do for the Debian release. Precedent set; precedent followed. I'll be hopefully packaging the _entire_ contrib tree :-) for beta 4, over the weekend. The only potential downside is that the contrib tree has (historically) not been as much shaken out for portability bugs as the main tree. You might find that some contrib items don't build, let alone run, everywhere. This probably isn't that big a danger for the RPMs, which only address a narrow subset of Unixen, but I recommend keeping your antennae up for possible problems. regards, tom lane
Re: [HACKERS] RPM: Contrib request.
Peter Eisentraut [EMAIL PROTECTED] writes: But, in the instance of pg_dumplo -- can I get some ideas on it? Should it be shipped as a separate package, or in the -server subpackage, or?? It shouldn't be packaged at all because it's not necessary. (pg_dump dumps large objects.) The reason pg_dumplo is still there at all is that it might be handy for forward compatibility for people who are using pg_dumplo with 7.0. (Yeah, I know it wasn't *in* the 7.0 release, but I've been sending out 7.0-compatible copies to anyone who asked about LO dumping lately.) I don't think pg_dumplo will be around for very many releases, but it deserves to stay in contrib for a little while yet. Meanwhile, it's not the RPMs' place to editorialize on which contrib items are useful. Package 'em all, unless we hit build problems. regards, tom lane
Re: [HACKERS] Permissions on CHECKPOINT
Peter Eisentraut [EMAIL PROTECTED] writes: Mikheev, Vadim writes: Yes, there should be permission checking - I'll add it later (in 7.1) if no one else. Should be simple enough. Is this okay: Actually, I think a more interesting question is "should CHECKPOINT have permission restrictions? If so, what should they be?" A quite relevant precedent is that Unix systems (at least the ones I've used) do not restrict who can call sync(). regards, tom lane
[HACKERS] Minor Sparc/Linux patch (regression test resultmap)....
Just a quick patch to make the geometry test on Sparc/Linux regression tests for Pgsql 7.1beta3 pass. This is very similr to the one I submitted back in July for Linux/Alpha. Apparently non-x86 Linux machines like to compute nth place float point digits like Sun/Solaris does? Otherwise, 7.1beta3 runs without problems (i.e. all other regression tests pass) on my Sparc 20 running Debian GNU/Linux 2.2. Thanks. --- | "For to me to live is Christ, and to die is gain."| |--- Philippians 1:21 (KJV) | --- | Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ | --- diff -uNr postgresql-7.1beta3/src/test/regress/resultmap postgresql-7.1beta3-sparc/src/test/regress/resultmap --- postgresql-7.1beta3/src/test/regress/resultmap Sat Jan 6 19:03:42 2001 +++ postgresql-7.1beta3-sparc/src/test/regress/resultmapThu Jan 25 21:59:53 +2001 @@ -28,6 +28,7 @@ geometry/powerpc-unknown-linux-gnu=geometry-powerpc-linux-gnulibc1 geometry/powerpc.*-aix4=geometry-powerpc-aix4 geometry/sparc-sun-solaris=geometry-solaris-precision +geometry/sparc.*-linux-gnu=geometry-solaris-precision geometry/alpha.*-linux-gnu=geometry-solaris-precision geometry/.*-beos=geometry-intel-beos horology/.*-aix4=horology-1947-PDT
[HACKERS] PQprint
Hi all, Re-posting this to -hackers. Will PQprint() remain/disappear/be replaced in the future? Thx Ed -- ÌĤ¯Ç¤ÏÁͤòÊá¤é¤Ì
Re: [HACKERS] Permissions on CHECKPOINT
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Mikheev, Vadim writes: Yes, there should be permission checking - I'll add it later (in 7.1) if no one else. Should be simple enough. Is this okay: Actually, I think a more interesting question is "should CHECKPOINT have permission restrictions? If so, what should they be?" A quite relevant precedent is that Unix systems (at least the ones I've used) do not restrict who can call sync(). What about DoS attacks? What would be the effect of someone's setting off an infinite loop of CHECKPOINTs? -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "Wash me thoroughly from mine iniquity, and cleanse me from my sin. For I acknowledge my transgressions; and my sin is ever before me. Against thee, thee only, have I sinned, and done this evil in thy sight..." Psalms 51:2-4
