[HACKERS] Re: Urgent Question on Postgresql
From: Bryan Wu [EMAIL PROTECTED]
Subject: Urgent Question on Postgresql
Date: Sun, 18 Mar 2001 04:39:36 -0800 (PST)
Message-ID: [EMAIL PROTECTED]
Hi tatsuo Ishii,
I learn from postgresql mailing list that you are
concerning the problem the UTF8 support in Postgresql.
Currently I want to choose a database to store chinese
(BIG5 and GB) information. Could you tell me if the
Postgresql can store information in UTF-8 format. I
think it is better for me to use UTF-8 since I need to
handle the Big5 and GB at the same time.
Yes.
I find very little information on how to configure the
postgresql to use default encoding UTF-8 when storing
data. Do you have any idea?
Enable the multibyte capability(configure --enable-multibyte) and
do createdb -E UNICODE.
And do you know if postgresql has any import tools so
I can import some chinese information directly to the
tables?
PostgreSQL 7.1 will be able to do an automatic conversion between
UTF-8 and Big5 or EUC-CN(GB). Here is a sample:
createdb -E UNICODE unicode
psql unicode
\encoding BIG5
insert into big_table values('some big5 data');
\encoding EUC_CN
insert into gb_table values('some EUC_CN data');
:
:
--
Tatsuo Ishii
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
[HACKERS] Re: problems with startup script on upgrade
Hi all On Fri, 16 Mar 2001, Martin A. Marques wrote: ld.so.1: /dbs/postgres/bin/postmaster: fatal: libz.so: open failed: No such file or directory Now, libz.so is in the LD_LIBRARY_PATH of the postgres user, so why is it that Solaris doesn't load the .profile in the postgres directory. The main trouble with all of this is that LD_LIBRARY_PATH is irrelevant here. From man ld.so.1: SECURITY To prevent malicious dependency substitution or symbol interposition, some restrictions may apply to the evaluation of the dependencies of secure processes. The runtime linker categorizes a process as secure if the user is not a super user, and either the real user and effective user identifiers are not equal, or the real group and effective group identifiers are not equal. See getuid(2), geteuid(2), getgid(2), and getegid(2). If an LD_LIBRARY_PATH environment variable is in effect for a secure process, then only the trusted directories speci- fied by this variable will be used to augment the runtime linker's search rules. Presently, the only trusted direc- tory known to the runtime linker is /usr/lib. There are many way to solve the problem: the easy -- copy (or link) libz.so to /usr/lib the clean -- avoid using LD_LIBRARY_PATH, use -R for linking instead Regards, ASK ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] pg_ctl problem (was Re: BeOS Patch)
Cyril VELTER [EMAIL PROTECTED] writes: pg_ctl output when no shm segments left pg_ctl: It seems another postmaster is running. Trying to start postmaster anyway. pg_ctl: cannot start postmaster not true !!! Examine the log output. DEBUG: database system was interrupted at 2001-03-18 12:01:57 CET DEBUG: CheckPoint record at (0, 20204684) DEBUG: Redo record at (0, 20204684); Undo record at (0, 0); Shutdown TRUE DEBUG: NextTransactionId: 5384; NextOid: 153313 DEBUG: database system was not properly shut down; automatic recovery in progress... DEBUG: ReadRecord: record with zero len at (0, 20204748) DEBUG: redo is not required DEBUG: database system is in production state Looking at the pg_ctl script, it seems this must be coming from eval '$po_path' '$POSTOPTS' $logopt '' if [ -f $PIDFILE ];then if [ "`sed -n 1p $PIDFILE`" = "$pid" ];then echo "$CMDNAME: cannot start postmaster" 12 echo "Examine the log output." 12 exit 1 fi fi which is clearly not giving the postmaster enough time to remove or rewrite the pidfile. Shouldn't we put a "sleep 1" in there before the "if"? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_ctl problem (was Re: BeOS Patch)
At a minimum, you should do a test, and if it does not yet exist, do a sleep, then the test again. Cyril VELTER [EMAIL PROTECTED] writes: pg_ctl output when no shm segments left pg_ctl: It seems another postmaster is running. Trying to start postmaster anyway. pg_ctl: cannot start postmaster not true !!! Examine the log output. DEBUG: database system was interrupted at 2001-03-18 12:01:57 CET DEBUG: CheckPoint record at (0, 20204684) DEBUG: Redo record at (0, 20204684); Undo record at (0, 0); Shutdown TRUE DEBUG: NextTransactionId: 5384; NextOid: 153313 DEBUG: database system was not properly shut down; automatic recovery in progress... DEBUG: ReadRecord: record with zero len at (0, 20204748) DEBUG: redo is not required DEBUG: database system is in production state Looking at the pg_ctl script, it seems this must be coming from eval '$po_path' '$POSTOPTS' $logopt '' if [ -f $PIDFILE ];then if [ "`sed -n 1p $PIDFILE`" = "$pid" ];then echo "$CMDNAME: cannot start postmaster" 12 echo "Examine the log output." 12 exit 1 fi fi which is clearly not giving the postmaster enough time to remove or rewrite the pidfile. Shouldn't we put a "sleep 1" in there before the "if"? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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: pg_ctl problem (was Re: BeOS Patch)
Tom Lane writes: eval '$po_path' '$POSTOPTS' $logopt '' if [ -f $PIDFILE ];then if [ "`sed -n 1p $PIDFILE`" = "$pid" ];then echo "$CMDNAME: cannot start postmaster" 12 echo "Examine the log output." 12 exit 1 fi fi which is clearly not giving the postmaster enough time to remove or rewrite the pidfile. Shouldn't we put a "sleep 1" in there before the "if"? This is probably the best we can do. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(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] new version of contrib-intarray
Bruce Momjian writes: I see change of += in CFLAGS (harmless), Not. movement of #include postgres.h, and removal of // comments, which don't appear anymore in the code. I only saw that the Makefile is back to how it looked at rev 1.1 before I did some work on it. AFAICT the Makefile should be reverted back to the previous revision, since the code change does not require any changes to the Makefile. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: problems with startup script on upgrade
Alexander Klimov writes: There are many way to solve the problem: the easy -- copy (or link) libz.so to /usr/lib the clean -- avoid using LD_LIBRARY_PATH, use -R for linking instead Our makefiles are set up to use '-R' for linking. Does this not work as designed? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(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] Trigger problem
Hi friends! I'm working in a trigger and I need to put the result of a query into a variable. That's very easy- apparently! The query has a aggregate function like this: select sum(field) into variable ... and I'm sure that field and variable are int4 type. So, when I run this trigger there is a mistake: ''there is no operator '=$' for types 'int4' and 'int4' you will either have to retype this query using an explicit cast, or you will have to define the operator using CREATE OPERATOR'' what's meaning this? and how can I assign the result of aggregate function into a variable? (My system is 6.5.3) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Allowing WAL fsync to be done via O_SYNC
The Hermit Hacker wrote: But, with shared libraries, are you really pulling in a "whole thread-support library"? My understanding of shared libraries (altho it may be totally off) was that instead of pulling in a whole library, you pulled in the bits that you needed, pretty much as you needed them ... Just by making a thread call libc changes personality to use thread safe routines (I.E. add mutex locking). Use one thread feature, get the whole set...which may not be that bad. -- William K. Volkman. CIO - H.I.S. Financial Services Corporation. 102 S. Tejon, Ste. 920, Colorado Springs, CO 80903 Phone: 719-633-6942 Fax: 719-633-7006 Cell: 719-330-8423 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: Beta6 for Tomorrow
Not sure if this counts as *major*, but this jdbc1 compile problem is presumably still there: http://www.postgresql.org/mhonarc/pgsql-bugs/2001-03/msg3.html as the referenced source file hasn't been updated. If I recall right, Peter was waiting for a java 1 SDK to be installed. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Performance monitor signal handler
On Fri, Mar 16, 2001 at 05:25:24PM -0500, Jan Wieck wrote: Jan Wieck wrote: ... Just to get some evidence at hand - could some owners of different platforms compile and run the attached little C source please? ... Seems Tom is (unfortunately) right. The pipe blocks at 4K. On NetBSD-1.5S/i386 with just the highly conservative shmem defaults: Pipe buffer is 4096 bytes Sys-V message queue buffer is 2048 bytes Cheers, Patrick ---(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: pg_ctl problem (was Re: BeOS Patch)
Peter Eisentraut [EMAIL PROTECTED] writes: which is clearly not giving the postmaster enough time to remove or rewrite the pidfile. Shouldn't we put a "sleep 1" in there before the "if"? This is probably the best we can do. Actually, the whole thing should only happen if we found a pre-existing PIDFILE anyway. Will fix. 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
Re: [HACKERS] Allowing WAL fsync to be done via O_SYNC
* William K. Volkman [EMAIL PROTECTED] [010318 11:56] wrote: The Hermit Hacker wrote: But, with shared libraries, are you really pulling in a "whole thread-support library"? My understanding of shared libraries (altho it may be totally off) was that instead of pulling in a whole library, you pulled in the bits that you needed, pretty much as you needed them ... Just by making a thread call libc changes personality to use thread safe routines (I.E. add mutex locking). Use one thread feature, get the whole set...which may not be that bad. Actually it can be pretty bad. Locked bus cycles needed for mutex operations are very, very expensive, not something you want to do unless you really really need to do it. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Beta6 for Tomorrow
Nat Howard writes: Not sure if this counts as *major*, but this jdbc1 compile problem is presumably still there: http://www.postgresql.org/mhonarc/pgsql-bugs/2001-03/msg3.html as the referenced source file hasn't been updated. If I recall right, Peter was waiting for a java 1 SDK to be installed. Care to submit a patch? This seems easy enough to fix for someone with an appropriate JDK installed. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(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] Trigger problem
jreniz [EMAIL PROTECTED] writes: So, when I run this trigger there is a mistake: ''there is no operator '=$' for types 'int4' and 'int4' (My system is 6.5.3) This is an old bug. Update to 7.0.3. It might work to add spaces around the '=' signs in your trigger function, but an update would be a good idea anyway. 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] Allowing WAL fsync to be done via O_SYNC
Alfred Perlstein [EMAIL PROTECTED] writes: Just by making a thread call libc changes personality to use thread safe routines (I.E. add mutex locking). Use one thread feature, get the whole set...which may not be that bad. Actually it can be pretty bad. Locked bus cycles needed for mutex operations are very, very expensive, not something you want to do unless you really really need to do it. It'd be interesting to try to get some numbers about the actual cost of using a thread-aware libc, on platforms where there's a difference. Shouldn't be that hard to build a postgres executable with the proper library and run some benchmarks ... anyone care to try? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Allowing WAL fsync to be done via O_SYNC
* Tom Lane [EMAIL PROTECTED] [010318 14:55]: Alfred Perlstein [EMAIL PROTECTED] writes: Just by making a thread call libc changes personality to use thread safe routines (I.E. add mutex locking). Use one thread feature, get the whole set...which may not be that bad. Actually it can be pretty bad. Locked bus cycles needed for mutex operations are very, very expensive, not something you want to do unless you really really need to do it. It'd be interesting to try to get some numbers about the actual cost of using a thread-aware libc, on platforms where there's a difference. Shouldn't be that hard to build a postgres executable with the proper library and run some benchmarks ... anyone care to try? I can get the code compiled, but don't have the skills to generate a test case worthy of anything LER regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Allowing WAL fsync to be done via O_SYNC
* Larry Rosenman [EMAIL PROTECTED] [010318 14:17] wrote:
* Tom Lane [EMAIL PROTECTED] [010318 14:55]:
Alfred Perlstein [EMAIL PROTECTED] writes:
Just by making a thread call libc changes personality to use thread
safe routines (I.E. add mutex locking). Use one thread feature, get
the whole set...which may not be that bad.
Actually it can be pretty bad. Locked bus cycles needed for mutex
operations are very, very expensive, not something you want to do
unless you really really need to do it.
It'd be interesting to try to get some numbers about the actual cost
of using a thread-aware libc, on platforms where there's a difference.
Shouldn't be that hard to build a postgres executable with the proper
library and run some benchmarks ... anyone care to try?
I can get the code compiled, but don't have the skills to generate
a test case worthy of anything
There's a 'make test' or something ('regression' maybe?) target that
runs a suite of tests on the database, you could use that as a
bench/timer, you could also try mysql's "crashme" script.
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
---(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] new version of contrib-intarray
Peter Eisentraut [EMAIL PROTECTED] writes: I only saw that the Makefile is back to how it looked at rev 1.1 before I did some work on it. AFAICT the Makefile should be reverted back to the previous revision, since the code change does not require any changes to the Makefile. I did this, also reinstalled the include-file changes I had made, and then spent several fruitless hours trying to find why the "intbig" index operators fail selftest here (on HP-PA). I suppose it's a portability problem, since presumably they pass for Oleg ... but I don't see it. Who else finds that the new contrib/intarray code passes or fails its selftest, and on what platforms? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Allowing WAL fsync to be done via O_SYNC
Larry Rosenman [EMAIL PROTECTED] writes: I can get the code compiled, but don't have the skills to generate a test case worthy of anything contrib/pgbench would do as a first cut. 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] new version of contrib-intarray
I wrote:
I did this, also reinstalled the include-file changes I had made, and
then spent several fruitless hours trying to find why the "intbig" index
operators fail selftest here (on HP-PA). I suppose it's a portability
problem, since presumably they pass for Oleg ... but I don't see it.
Further experimentation shows that intbig fails selftest on ALL
platforms under 7.1. I see the problem: the intarray operators are
mostly unprepared to cope with TOASTed input arrays. In particular,
_intbig_union() generates an erroneous "null" result for a compressed
input array, leading to completely incorrect GiST index trees in the
self-test example.
A somewhat-related error in this code is that some routines feel free
to scribble on their input. This is tres uncool, because they may be
scribbling on disk buffers. Example:
regression=# create table foo(f1 int4[]);
CREATE
regression=# insert into foo values ('{10,1,2,1,4}');
INSERT 150265 1
regression=# select * from foo;
f1
--
{10,1,2,1,4}
(1 row)
regression=# select * from foo where f1 '{4}';
f1
--
{1,1,2,4,10}
(1 row)
regression=# select * from foo;
f1
--
{1,1,2,4,10}
(1 row)
And you thought SELECT was a read-only operation ...
I do not have time to work on this stuff now, but as it stands the
contrib/intarray code is unusable in 7.1. Unless Oleg can find the
time to fix these issues before release, I will recommend that we
not ship contrib/intarray in 7.1.
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: Small bug in pg_dump
At 19:10 14/03/01 -0500, Tom Lane wrote: It might even make sense for an ArchiveEntry to store both forms of the name, and then using code could just select the form wanted instead of calling fmtId repeatedly. Not sure. BTW, making the -t switch compare to the unquoted name would probably also fix the bizarre need for '"Foo"' exhibited above. I think these are both fixed now; the SQL in the ArchiveEntry call still uses the formatted names, but the name in the TOC entry is unformatted in all cases except functions now. The TOC entry name is used in the -t switch and in disabling triggers etc. This does make me wonder (again) about some kind of pg_dump regression test. ISTM that a test should be doable by building a DB from data files, dumping it, restoring it, then using COPY to extract the data back to files (and probably doing a sort on the output). We could also store a BLOB or two. Then we compare the initial data files with the final ones. This will test the integrity of the data BLOB dump/restore. We then also need to test the metadata integrity somehow, probably by dumping restoring the regression DB, but we'd need to modify the pg_dump output somewhat, I think. 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 |/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Dropping CHECK constraints
In 7.0.3, is it safe to drop a check constraint by simply deleting it from the pg_relcheck table? Chris -- Christopher Kings-Lynne Family Health Network (ACN 089 639 243) ---(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] Dropping CHECK constraints
Doh! Not reltriggers - I meant relchecks... Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher Kings-Lynne Sent: Monday, March 19, 2001 10:53 AM To: Hackers Subject: [HACKERS] Dropping CHECK constraints In 7.0.3, is it safe to drop a check constraint by simply deleting it from the pg_relcheck table? Chris -- Christopher Kings-Lynne Family Health Network (ACN 089 639 243) ---(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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
RE: [HACKERS] Dropping CHECK constraints
OK, I notice I have to decrement the reltriggers field in the pg_class directory as well, but other than that is there any problem? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher Kings-Lynne Sent: Monday, March 19, 2001 10:53 AM To: Hackers Subject: [HACKERS] Dropping CHECK constraints In 7.0.3, is it safe to drop a check constraint by simply deleting it from the pg_relcheck table? Chris -- Christopher Kings-Lynne Family Health Network (ACN 089 639 243) ---(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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Beta6 for Tomorrow
Peter, I'll give it a try, and send the stuff to you directly, so you can say something like "that isn't what I meant!". Nat Howard writes: Not sure if this counts as *major*, but this jdbc1 compile problem is presumably still there: http://www.postgresql.org/mhonarc/pgsql-bugs/2001-03/msg3.html as the referenced source file hasn't been updated. If I recall right, Peter was waiting for a java 1 SDK to be installed. Care to submit a patch? This seems easy enough to fix for someone with an appropriate JDK installed. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(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] Dropping CHECK constraints
"Christopher Kings-Lynne" [EMAIL PROTECTED] writes: In 7.0.3, is it safe to drop a check constraint by simply deleting it from the pg_relcheck table? You'll need to adjust the relchecks count in the table's pg_class entry as well. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Performance monitor signal handler
Jan Wieck [EMAIL PROTECTED] writes: Just to get some evidence at hand - could some owners of different platforms compile and run the attached little C source please? (The program tests how much data can be stuffed into a pipe or a Sys-V message queue before the writer would block or get an EAGAIN error). One final followup on this --- I wasted a fair amount of time just now trying to figure out why Perl 5.6.0 was silently hanging up in its self-tests (at op/taint, which seems pretty unrelated...). The upshot: Jan's test program had left a 16k SysV message queue hanging about, and that queue was filling all available SysV message space on my machine. Seems Perl tries to test message-queue sending, and it was patiently waiting for some message space to come free. In short, the SysV message queue limits are so tiny that not only are you quite likely to get bollixed up if you use messages, but you're likely to bollix anything else that's using message queues too. 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] query on PostgreSQL-JDBC driver
Hello All! I have found the PostgreSQL - JDBC driver from the site http://www.retep.org.uk/postgres/. But, Iam not finding any tutorial for the same. Can anybody tell me the name of the site where I can find both the PostgreSQL driver and tutorial containing the examples . With regards, Sourabh Dixit ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] new version of contrib-intarray
I just returned from vacation and identified the problem.
We'll fix it.
Regards,
Oleg
On Sun, 18 Mar 2001, Tom Lane wrote:
I wrote:
I did this, also reinstalled the include-file changes I had made, and
then spent several fruitless hours trying to find why the "intbig" index
operators fail selftest here (on HP-PA). I suppose it's a portability
problem, since presumably they pass for Oleg ... but I don't see it.
Further experimentation shows that intbig fails selftest on ALL
platforms under 7.1. I see the problem: the intarray operators are
mostly unprepared to cope with TOASTed input arrays. In particular,
_intbig_union() generates an erroneous "null" result for a compressed
input array, leading to completely incorrect GiST index trees in the
self-test example.
A somewhat-related error in this code is that some routines feel free
to scribble on their input. This is tres uncool, because they may be
scribbling on disk buffers. Example:
regression=# create table foo(f1 int4[]);
CREATE
regression=# insert into foo values ('{10,1,2,1,4}');
INSERT 150265 1
regression=# select * from foo;
f1
--
{10,1,2,1,4}
(1 row)
regression=# select * from foo where f1 '{4}';
f1
--
{1,1,2,4,10}
(1 row)
regression=# select * from foo;
f1
--
{1,1,2,4,10}
(1 row)
And you thought SELECT was a read-only operation ...
I do not have time to work on this stuff now, but as it stands the
contrib/intarray code is unusable in 7.1. Unless Oleg can find the
time to fix these issues before release, I will recommend that we
not ship contrib/intarray in 7.1.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
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
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: pg_upgrade
Since pg_upgrade will not work for 7.1, should its installation be prevented and the man page be disabled? Probably. I am not sure it will ever be used again now that we have numeric file names. Perhaps we should leave it for 7.1 because people will complain when they can not find it. Maybe we can mention this may go away in the next release. If it doesn't work, and will not be made to work, then let's remove it from the tree. If someone wants to resurrect it, then it is easily retrieved from the cvs attic. But istm that it is not a bad thing if people can not find something which will not work ;) Comments? - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: pg_upgrade
Thomas Lockhart [EMAIL PROTECTED] writes: If it doesn't work, and will not be made to work, then let's remove it from the tree. I tend to agree with Peter's slightly less drastic proposal: remove it from the installed fileset and disable its man page, without necessarily 'cvs remove'ing all the source files. (I see we have already removed all the other documentation references to it, so disconnecting the ref page from reference.sgml should be sufficient.) I hope that pg_upgrade will be of use again in the future, so even though it can't work for 7.1, a scorched-earth policy is not the way to go... 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
