Re: [HACKERS] vacuum crash on 6.5.3
Althoug this happens on old 6.5.3, I would like to know if this has
been already fixed...
Here is the scenario:
1) before vacuum, table A has 8850 tuples.
2) vacuum on table A makes postgres crashed.
3) it crashes at line 1758:
Assert(num_moved == checked_moved);
I examined variables using gdb. num_moved == 8849, check_moved ==
8813, num_tuples == 18.
4) if PostgreSQL is not compiled with assertion, vacuum does not
crash. However, after vacuum, the number of tuples descreases from
8850 to 8814!! (I am not sure which number is correct, though)
I think this is an important problem since a data loss might
happen. Any idea?
It turns out that this was caused by vacuum's bug. Thanks to Hiroshi,
he has identified the problem. I have checked other version of
PostgreSQL, and found that at we have had the bug at least since
6.3.2, and it has been fixed in 7.0. Included are patches for 6.5.3 and
a test sript to reproduce the bug. Both of them are made by Hiroshi.
--
Tatsuo Ishii
drop sequence t1_i_seq;
drop table t1;
create table t1 (i serial, t text);
insert into t1(t) values(rpad('x',2048,'x'));
insert into t1(t) values(rpad('x',2048,'x'));
insert into t1(t) values(rpad('x',2048,'x'));
insert into t1(t) values(rpad('x',2048,'x'));
insert into t1(t) values(rpad('x',2048,'x'));
insert into t1(t) values(rpad('x',2048,'x'));
insert into t1(t) values(rpad('x',2048,'x'));
insert into t1(t) values(rpad('x',2048,'x'));
insert into t1(t) values(rpad('x',2048,'x'));
insert into t1(t) values(rpad('x',3970,'x'));
insert into t1(t) values(rpad('x',3970,'x'));
insert into t1(t) values(rpad('x',3970,'x'));
insert into t1(t) values(rpad('x',3970,'x'));
insert into t1(t) values(rpad('x',2048,'x'));
insert into t1(t) values(rpad('x',2048,'x'));
insert into t1(t) values(rpad('x',2048,'x'));
insert into t1(t) values(rpad('x',2048,'x'));
insert into t1(t) values(rpad('x',2048,'x'));
insert into t1(t) values(rpad('x',2048,'x'));
insert into t1(t) values(rpad('x',3970,'x'));
insert into t1(t) values(rpad('x',3970,'x'));
insert into t1(t) values(rpad('x',3970,'x'));
select ctid,i,char_length(t) from t1;
delete from t1 where i = 1;
delete from t1 where i = 4;
delete from t1 where i = 7;
delete from t1 where i = 10;
delete from t1 where i = 11;
delete from t1 where i = 12;
delete from t1 where i = 13;
delete from t1 where i = 14;
delete from t1 where i = 15;
delete from t1 where i = 16;
select ctid,i,char_length(t) from t1;
vacuum t1;
select ctid,i,char_length(t) from t1;
select version();
*** commands/vacuum.c.orig Tue Dec 26 23:24:01 2000
--- commands/vacuum.c Wed Dec 27 00:36:46 2000
***
*** 1025,1030
--- 1025,1031
*idcur;
int last_fraged_block,
last_vacuum_block,
+ last_moved_in_block,
i = 0;
Sizetuple_len;
int num_moved,
***
*** 1060,1065
--- 1061,1067
vacuumed_pages = vacuum_pages-vpl_num_pages -
vacuum_pages-vpl_empty_end_pages;
last_vacuum_page = vacuum_pages-vpl_pagedesc[vacuumed_pages - 1];
last_vacuum_block = last_vacuum_page-vpd_blkno;
+ last_moved_in_block = 0;
Assert(last_vacuum_block = last_fraged_block);
cur_buffer = InvalidBuffer;
num_moved = 0;
***
*** 1073,1078
--- 1075,1083
/* if it's reapped page and it was used by me - quit */
if (blkno == last_fraged_block last_fraged_page-vpd_offsets_used
0)
break;
+ /* couldn't shrink any more if this block has MOVED_IN tuplesit's -
+quit */
+ if (blkno == last_moved_in_block)
+ break;
buf = ReadBuffer(onerel, blkno);
page = BufferGetPage(buf);
***
*** 1447,1452
--- 1452,1459
pfree(newtup.t_data);
newtup.t_data = (HeapTupleHeader)
PageGetItem(ToPage, newitemid);
ItemPointerSet((newtup.t_self),
vtmove[ti].vpd-vpd_blkno, newoff);
+ if (vtmove[i].vpd-vpd_blkno
+last_moved_in_block)
+ last_moved_in_block =
+vtmove[i].vpd-vpd_blkno;
/*
* Set t_ctid pointing to itself for last
tuple in
***
*** 1579,1584
--- 1586,1593
newtup.t_data = (HeapTupleHeader) PageGetItem(ToPage,
newitemid);
ItemPointerSet((newtup.t_data-t_ctid), cur_page-vpd_blkno,
newoff);
newtup.t_self = newtup.t_data-t_ctid;
+ if (cur_page-vpd_blkno last_moved_in_block)
+
Re: [HACKERS] Upper limit on number of buffers?
On Sun, 24 Dec 2000, Joe Conway wrote: Linux The default shared memory limit (both SHMMAX and SHMALL) is 32 MB in 2.2 kernels, but it can be changed in the proc file system (without reboot). For example, to allow 128 MB: $ echo 134217728 /proc/sys/kernel/shmall $ echo 134217728 /proc/sys/kernel/shmmax You could put these commands into a script run at boot-time. On redhat 6.2 I know that you can use /etc/sysctl.conf to do this as well. Just add this to /etc/sysctl.conf. kernel.shmall = 134217728 kernel.shmmax = 134217728 After this, your tunables will be restored every time that the system boots. Mike
RE: [HACKERS] Assuming that TAS() will succeed the first time is verboten
The code is based on some odd assumptions. A select() with 0 delay returns immediately unless there is an interrupt during its (very short!) time in kernel space. Yeah, I've wondered whether the 0 entries in s_spincycle[] shouldn't be 1. The code author evidently expected select() to at least yield the processor even with delay 0, but the select() man pages I have handy say that it will "return immediately" when delay is 0. I've run some tests with 5 instead of 0 and afair performance was worse, so we should carefully test !0 values. Actually, one slocks are held longer than anothers - probably we should use different delays... Vadim
Re: [HACKERS] About PQsetClientEncoding(),SET NAMES,and SET CLIENT_ENCODING
We have merged README.mb into the official SGML docs, so the file is
gone. Not sure what setup we have for SGML docs in different languages.
Sorry.
---
Tatsuo Ishii wrote:
Here are the patches I promised against PHP
3.0.15 or later.
To set the client encoding to BIG5:
pg_setclientencoding($cid, "BIG5");
($cid is the connection id)
To get the current client encoding:
pg_clientencoding($cid);
Note that these fucntions are already included in the latest PHP4.
Thank you!
Your README.mb has been translate into Chinese (Big5 encoding) in the
attachement.
Would someone like to review it?
After translating it, I still have one question: (Sorry, I have not read the
source code.)
What is the difference among "libpq -- PQsetClientEncoding()",
"SQL command -- SET NAMES", and
"SQL command -- SET CLIENT_ENCODING"?
For example: If we use PHP (4.0.2), which way is correct or mostly correct?
1. pg_setclientencoding($cid, "BIG5")
2. pg_exec("SET NAMES 'BIG5'")
3. pg_exec("SET CLIENT_ENCODING TO 'BIG5'")
--
Chih-Chang Hsieh
--
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
[HACKERS] Notify with Rules bugs?
Hi! I compiled the 7.1 version of the snapshot dated on the December 18 (on i386 Linux Red Hat 6.1). Using the notify in the rule actions I get some errors and I suppose they are bugs. The first one when the rule is triggered: [postgres@ postgres]$ createdb test CREATE DATABASE test=# create table test_notify(one int); CREATE test=# create rule i_test_notify as on insert to test_notify do notify ONE; CREATE test=# insert into test_notify values (1); 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 second one (exactly, this is not a bug) when I try to see the rule definition. test=# select * from pg_rules; ERROR: get_ruledef of i_test_notify: query command type 5 not implemented yet Finally, when a dump of the database is performed: [postgres@ postgres]$ pg_dump test test.pgdump dumpRules(): SELECT failed for rules associated with table "test_notify". Explanation from backend: 'ERROR: get_ruledef of i_test_notify: query command type 5 not implemented yet '. This error is produced in the same way as in the previous case but in this case, there is an additional problem since the dump aborts. Within the patch I attach, you can find the solution for these problems: To solve the first error the function gatherRewriteMeta in RewriteHandler.c was modified To solve the second and third errors the function get_utility_query_def in ruleutils.c was added. The function get_query_def in ruleutils.c was modified as well. Would someone like to review it? Thnaks. Sergio. notify_rules. patch.gz
Re: [HACKERS] GNU readline and BSD license
* The Hermit Hacker [EMAIL PROTECTED] [001229 14:11] wrote: On Sat, 23 Dec 2000, Bruce Momjian wrote: FreeBSD has a freely available library called 'libedit' that could be shipped with postgresql, it's under the BSD license. Yes, that is our solution if we have a real problem here. Is there a reason *not* to move towards that for v7.2 so that the functions we are making optional with readline are automatic? Since we could then ship the code, we could make it a standard vs optional "feature" ... My thought would be to put 'make history feaure standard using libedit' onto the TODO list and take it from there ... I doubt I'd have the time to do it, but if you guys want to use libedit it'd probably be a good idea at least to reduce the amount of potential GPL tainting in the source code. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
Re: [HACKERS] GNU readline and BSD license
On Fri, 29 Dec 2000, The Hermit Hacker wrote: On Sat, 23 Dec 2000, Bruce Momjian wrote: FreeBSD has a freely available library called 'libedit' that could be shipped with postgresql, it's under the BSD license. Yes, that is our solution if we have a real problem here. Is there a reason *not* to move towards that for v7.2 so that the functions we are making optional with readline are automatic? Since we could then ship the code, we could make it a standard vs optional "feature" ... Also, it might be beneficial to _not_ link postmaster/postgres against libreadline - I don't see where either of those programs need it - sure, psql, but the backends? ... morannon:~ldd `which postgres` libz.so.1 = /usr/lib/libz.so.1 (0x40019000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x40028000) libnsl.so.1 = /lib/libnsl.so.1 (0x40055000) libdl.so.2 = /lib/libdl.so.2 (0x4006c000) libm.so.6 = /lib/libm.so.6 (0x4007) libreadline.so.3 = /lib/libreadline.so.3 (0x4008d000) libtermcap.so.2 = /usr/lib/libtermcap.so.2 (0x400b5000) libncurses.so.4 = /lib/libncurses.so.4 (0x400b9000) libc.so.6 = /lib/libc.so.6 (0x400ff000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) morannon:~ldd `which psql` libpq.so.2.1 = /usr/lib/libpq.so.2.1 (0x40019000) libz.so.1 = /usr/lib/libz.so.1 (0x40028000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x40037000) libnsl.so.1 = /lib/libnsl.so.1 (0x40064000) libdl.so.2 = /lib/libdl.so.2 (0x4007b000) libm.so.6 = /lib/libm.so.6 (0x4007f000) libreadline.so.3 = /lib/libreadline.so.3 (0x4009d000) libtermcap.so.2 = /usr/lib/libtermcap.so.2 (0x400c4000) libncurses.so.4 = /lib/libncurses.so.4 (0x400c8000) libc.so.6 = /lib/libc.so.6 (0x4010e000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) postgres/postmaster very likely don't need either libreadline, nor libncurses... Unless there's something I'm missing. -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli --- http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/
Re: [HACKERS] GNU readline and BSD license
On Fri, 29 Dec 2000, Alfred Perlstein wrote: * The Hermit Hacker [EMAIL PROTECTED] [001229 14:11] wrote: On Sat, 23 Dec 2000, Bruce Momjian wrote: FreeBSD has a freely available library called 'libedit' that could be shipped with postgresql, it's under the BSD license. Yes, that is our solution if we have a real problem here. Is there a reason *not* to move towards that for v7.2 so that the functions we are making optional with readline are automatic? Since we could then ship the code, we could make it a standard vs optional "feature" ... My thought would be to put 'make history feaure standard using libedit' onto the TODO list and take it from there ... I doubt I'd have the time to do it, but if you guys want to use libedit it'd probably be a good idea at least to reduce the amount of potential GPL tainting in the source code. I'm all for trying to take it on ... Bruce, put me down for it ...
[HACKERS] NULLS and : Discrepancies ?
Sorry for intruding, but the following question did not get much attention on the "General" list. However, I still need the answer ... /LurkingMode NewbieMode Could some kind soul explain this to me ? test1=# select distinct "Cle" from "Utilisateurs"; Cle - 1 2 3 4 (4 rows) test1=# select distinct "CleUtil" from "Histoires"; CleUtil - 1 (2 rows) -- Uuhhh ! test1=# select count(*) as NbRec from "Histoires" where "CleUtil" is null; nbrec --- 2 (1 row) -- Ah Ahh ... I have NULLs. test1=# select distinct "Cle" from "Utilisateurs" where "Cle" in test1-# (select distinct "CleUtil" from "Histoires"); Cle - 1 (1 row) -- That's OK ... test1=# select distinct "Cle" from "Utilisateurs" where "Cle" not in test1-# (select distinct "CleUtil" from "Histoires"); Cle - (0 rows) -- That's definitively *NOT* OK ! However test1=# select distinct "Cle" from "Utilisateurs" where "Cle" not in test1-# (select distinct "CleUtil" from "Histoires" where "CleUtil" is not null); Cle - 2 3 4 (3 rows) -- That's what I expected in the first place. Could someone explain to me why not eliminating nulls destroys the potential results of the query ? In other words, for any X not null, X not in (some NULLs) is false. /NewbieMode LurkingMode Emmanuel Charpentier
[HACKERS] as i work BLOB's from PostODBC
Hi !! I'm using PostgreSQL 7.0.2 with Linux Mandrake 7.2, and not know as send general data type or BLOB's to my win32 ODBC driver (PostODBC) from Visual Fox Pro. If yours have examples or source code of apps that sending/receive big binaries data via ODBC, write me !!.. Help me friends !!
[HACKERS] how do i store \0 inside a text attribute?
for my pgcat utility i now know i have to use \nnn octal quoting for nonprintables in the generated INSERT commands. but in testing, i found the following oddity. this is in 7.1-b1 (cvs-current). vixie= create table foo ( bar text ); CREATE vixie= insert into foo values ( 'a\033b' ); INSERT 728084 1 vixie= select length(bar) from foo; length -- 3 (1 row) great! it stored the escape. and since SELECT's front/back end protocol is counted-string rather than quoted text, it comes back reliably (though i still intend to try a binary cursor at some point, just to do it.) BUT: vixie= delete from foo; DELETE 1 vixie= insert into foo values ( 'a\0b' ); INSERT 728085 1 vixie= select length(bar) from foo; length -- 1 (1 row) vixie= drop table foo; DROP vixie= \q this is not what i was hoping for at ALL. evidently the implementation of text assumes NUL-termination in other places than the parser. ultimately this means that pgsql will need a "blob" type whose presentation format is uuencode or some such. but is there a workaround for this using "text"? how would someone be expected to store, say, a GIF image in a TOAST text?
[HACKERS] Regress-test failure in current sources
With this afternoon's CVS sources, I got a failure in the 'polygon'
regression test while running the parallel-mode tests:
--
CREATE TABLE POLYGON_TBL(f1 polygon);
+ ERROR: heap_update: (am)invalid tid
INSERT INTO POLYGON_TBL(f1) VALUES ('(2.0,0.0),(2.0,4.0),(0.0,0.0)');
(plus many subsequent diffs arising from the lack of polygon_tbl).
This doesn't seem to be very repeatable --- I've only seen it once in
about a dozen tries. But there's a problem in there somewhere. I am
cycling the tests now in hopes of duplicating the failure.
There are only four heap_update() calls performed during this command,
all arising directly or indirectly from creation of the TOAST table:
#1 0xbe110 in UpdateStats (relid=10, reltuples=1000) at index.c:1742
#1 0xbe110 in UpdateStats (relid=1, reltuples=1000) at index.c:1742
#1 0xbdb70 in setRelhasindex (relid=145156, hasindex=1 '\001') at index.c:1487
#1 0xddd78 in AlterTableCreateToastTable (relationName=0x23710 "",
silent=-48 'Å') at command.c:1696
My suspicions are focused on the last one in AlterTableCreateToastTable,
but I can't prove it yet ...
Has anyone else seen something like this? Any ideas what's wrong?
regards, tom lane
Re: [HACKERS] GNU readline and BSD license
On Sat, Dec 23, 2000 at 08:42:43AM -0800, Alfred Perlstein wrote: FreeBSD has a freely available library called 'libedit' that could be shipped with postgresql, it's under the BSD license. If you have access to a FreeBSD box see the editline(3) manpage, or go to: http://www.freebsd.org/cgi/man.cgi?query=editlineapropos=0sektion=0manpath=FreeBSD+4.2-RELEASEformat=html Good plan - AFAIK there isn't anything gnu readline can do that libedit can't.. Patrick
Re: [HACKERS] NULLS and : Discrepancies ?
Could someone explain to me why not eliminating nulls destroys the potential results of the query ? In other words, for any X not null, X not in (some NULLs) is false. You already know the answer: comparisons to NULL always evaluate to false. You may conclude that this exposes a flaw in SQL9x's definition of three-value logic, but is the result you should expect for a standards-compliant SQL implementation. - Thomas (I was going to say "almost always" rather than "always" but I'm not recalling a counter example and don't have time to look it up. Sorry about that... ;)
Re: [HACKERS] GNU readline and BSD license
Lamar Owen [EMAIL PROTECTED] writes: How different is the feature set? I was going to ask the same thing. If it's an exact replacement then OK, but I do not want to put up with non-Emacs-compatible keybindings, to mention just one likely issue. The whole thing really strikes me as make-work anyway. Linux is GPL'd; does anyone want to argue that we shouldn't run on Linux? Since we are not including libreadline in our distribution, there is NO reason to worry about using it when it's available. Wanting to find a replacement purely because of the license amounts to license bigotry, IMHO. regards, tom lane
Re: [HACKERS] how do i store \0 inside a text attribute?
Paul A Vixie [EMAIL PROTECTED] writes: this is not what i was hoping for at ALL. evidently the implementation of text assumes NUL-termination in other places than the parser. Yes. The entire datatype I/O system is based on null-terminated strings, so there's no easy way to fix this. If it were just an internal problem then maybe we'd bite the bullet and do it, but breaking every user-defined datatype in existence seems too high a price to pay for this problem. ultimately this means that pgsql will need a "blob" type whose presentation format is uuencode or some such. See bytea, though its presentation format leaves something to be desired IMHO. how would someone be expected to store, say, a GIF image in a TOAST text? One would not. A TOASTed bytea is the appropriate column type. regards, tom lane
Re: [HACKERS] GNU readline and BSD license
* Tom Lane [EMAIL PROTECTED] [001229 15:43] wrote: Lamar Owen [EMAIL PROTECTED] writes: How different is the feature set? I was going to ask the same thing. If it's an exact replacement then OK, but I do not want to put up with non-Emacs-compatible keybindings, to mention just one likely issue. The whole thing really strikes me as make-work anyway. Linux is GPL'd; does anyone want to argue that we shouldn't run on Linux? Since we are not including libreadline in our distribution, there is NO reason to worry about using it when it's available. Wanting to find a replacement purely because of the license amounts to license bigotry, IMHO. Rasmus Lerdorf warned one of you guys that simply linking to GNU readline can contaminate code with the GPL. Readline isn't LGPL which permits linking without lincense issues, it is GPL which means that if you link to it, you must be GPL as well. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
Re: [HACKERS] GNU readline and BSD license
The Hermit Hacker [EMAIL PROTECTED] writes: Actually, IMHO, the pro to moving to libedit is that we could include it as part of the distribution and make history a *standard* feature How big is libedit? If it's tiny, that might be a good argument ... but I don't want to see us bulking up our distro with something that people could and should get directly from its source. regards, tom lane
Re: [HACKERS] GNU readline and BSD license
On Fri, 29 Dec 2000, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: How different is the feature set? I was going to ask the same thing. If it's an exact replacement then OK, but I do not want to put up with non-Emacs-compatible keybindings, to mention just one likely issue. The whole thing really strikes me as make-work anyway. Linux is GPL'd; does anyone want to argue that we shouldn't run on Linux? Since we are not including libreadline in our distribution, there is NO reason to worry about using it when it's available. Wanting to find a replacement purely because of the license amounts to license bigotry, IMHO. Actually, IMHO, the pro to moving to libedit is that we could include it as part of the distribution and make history a *standard* feature ... licensing started the thread, but I think its gone beyond that were we have a way of providing an feature that is currently option as part of the system as a whole ... "one less package that you need to install" ...
Re: [HACKERS] GNU readline and BSD license
thelab# du -sk libedit
402 libedit
thelab# ls
Makefileel.hmap.c refresh.h tokenizer.c
TESTemacs.c map.h search.ctokenizer.h
chared.chist.c parse.c search.htty.c
chared.hhist.h parse.h sig.c tty.h
common.chistory.c prompt.csig.h vi.c
editline.3 key.c prompt.hsys.h
editrc.5key.h read.c term.c
el.cmakelistrefresh.c term.h
its tiny ...
we'd be adding a whole 79k to the 6meg distribution:
ls -lt /tmp/libedit.tar.gz
-rw-r--r-- 1 scrappy wheel 79025 Dec 29 20:38 /tmp/libedit.tar.gz
and providing all the functionality that ppl who don't have libreadline
already installed don't get ...
On Fri, 29 Dec 2000, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Actually, IMHO, the pro to moving to libedit is that we could include it
as part of the distribution and make history a *standard* feature
How big is libedit? If it's tiny, that might be a good argument ...
but I don't want to see us bulking up our distro with something that
people could and should get directly from its source.
regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
Re: [HACKERS] GNU readline and BSD license
* Peter Eisentraut [EMAIL PROTECTED] [001229 16:01] wrote: The Hermit Hacker writes: Is there a reason *not* to move towards that for v7.2 so that the functions we are making optional with readline are automatic? Since we could then ship the code, we could make it a standard vs optional "feature" ... My thought would be to put 'make history feaure standard using libedit' onto the TODO list and take it from there ... In my mind this is a pointless waste of developer time because there is no problem to solve here. I'm sure we all have better things to do than porting libedit to a dozen systems and then explaining to users why the tarball is bloated and their carefully composed readline configuration doesn't work anymore. If there is something functionally wrong with Readline then let's talk about it, but let's not replace it with something because some PHP dude said that RMS said something. From http://www.gnu.org/copyleft/gpl.html This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License. My understanding (from the recent discussion) is that Postgresql has certain dependancies on libreadline and won't compile/work without it, if true this effectively forces anyone wishing to derive a viable commercial product based on Postgresql to switch to the GPL or port to libedit anyway. If readline is completely optional then there's really no problem. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
Re: [HACKERS] GNU readline and BSD license
Alfred Perlstein [EMAIL PROTECTED] writes: Rasmus Lerdorf warned one of you guys that simply linking to GNU readline can contaminate code with the GPL. Readline isn't LGPL which permits linking without lincense issues, it is GPL which means that if you link to it, you must be GPL as well. I do not believe that. In fact, I'll go further and say "Horsepucky!" The GPL applies to works that "contain or are derived from" a GPL'd program. Linking to a separately distributed library does not cause psql either to contain or to be derived from libreadline. If we distributed binary executables that contained statically linked copies of libreadline, then indeed we'd have a problem. We do not, AFAIK, and we have no intention of doing so in the future. regards, tom lane
Re: [HACKERS] NULLS and : Discrepancies ?
Thomas Lockhart [EMAIL PROTECTED] writes: Could someone explain to me why not eliminating nulls destroys the potential results of the query ? In other words, for any X not null, X not in (some NULLs) is false. You already know the answer: comparisons to NULL always evaluate to false. Thomas, I'm surprised at you! Comparisons to NULL do not yield false, they yield NULL. So, given foo NOT IN (bar, NULL) we may rewrite this as NOT (foo IN (bar, NULL)) NOT (foo = bar OR foo = NULL) NOT (false OR NULL) NOT (NULL) NULL On the other hand foo NOT IN (foo, NULL) NOT (foo IN (foo, NULL)) NOT (foo = foo OR foo = NULL) NOT (true OR NULL) NOT (true) false So the correct statement of the behavior is that the result of NOT IN is always either FALSE or NULL if there are any NULLs involved. This is perfectly correct if you recall the interpretation of NULL as "don't know". The truth value of "foo = NULL" is not FALSE, it is UNKNOWN, because you don't know what the NULL is ... it could be foo. It happens that WHERE treats a NULL condition result the same as FALSE, ie don't select the row, but they are not the same thing. regards, tom lane
Re: [HACKERS] GNU readline and BSD license
* Tom Lane [EMAIL PROTECTED] [001229 16:38] wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Actually, IMHO, the pro to moving to libedit is that we could include it as part of the distribution and make history a *standard* feature How big is libedit? If it's tiny, that might be a good argument ... but I don't want to see us bulking up our distro with something that people could and should get directly from its source. ~350k -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
Re: [HACKERS] GNU readline and BSD license
Alfred Perlstein [EMAIL PROTECTED] writes: My understanding (from the recent discussion) is that Postgresql has certain dependancies on libreadline and won't compile/work without it, Then you're working from a misconception. regards, tom lane
Re: [HACKERS] GNU readline and BSD license
* The Hermit Hacker [EMAIL PROTECTED] [001229 17:06] wrote: On Fri, 29 Dec 2000, Tom Lane wrote: Alfred Perlstein [EMAIL PROTECTED] writes: My understanding (from the recent discussion) is that Postgresql has certain dependancies on libreadline and won't compile/work without it, Then you're working from a misconception. I think the misconception that he might be working on here is the point someone brought up that when configure runs, it is adding -lreadline to the backend compile, even though that I don't think there is any reason for doing such? I thought psql required libreadline, I'm not sure who said it. If nothing requires it then there's not much point in moving to libedit from a devel cost/benifit analysis. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
Re: [HACKERS] GNU readline and BSD license
On Fri, 29 Dec 2000, Tom Lane wrote: Alfred Perlstein [EMAIL PROTECTED] writes: My understanding (from the recent discussion) is that Postgresql has certain dependancies on libreadline and won't compile/work without it, Then you're working from a misconception. I think the misconception that he might be working on here is the point someone brought up that when configure runs, it is adding -lreadline to the backend compile, even though that I don't think there is any reason for doing such?
Re: [HACKERS] GNU readline and BSD license
On Fri, Dec 29, 2000 at 07:15:05PM -0500, Tom Lane wrote: Alfred Perlstein [EMAIL PROTECTED] writes: Rasmus Lerdorf warned one of you guys that simply linking to GNU readline can contaminate code with the GPL. Readline isn't LGPL which permits linking without lincense issues, it is GPL which means that if you link to it, you must be GPL as well. I do not believe that. In fact, I'll go further and say "Horsepucky!" The GPL applies to works that "contain or are derived from" a GPL'd program. Linking to a separately distributed library does not cause psql either to contain or to be derived from libreadline. RMS already made a big stink about this, claiming that BeOS's use of an emulation layer to link to some GPL'ed network drivers was enough to force the GPL'ing of the kernel. Be backed down (and re-licensed the code from the source, IIRC). Sun recently released a "driver porting kit" that allowed similar drivers to be used in Solaris. There was some outcry on Slashdot, but I'm not sure how it ended up. I wouldn't mind having someone tell RMS to fuck off, though. -- Adam Haberlach|A cat spends her life conflicted between a [EMAIL PROTECTED] |deep, passionate, and profound desire for http://www.newsnipple.com |fish and an equally deep, passionate, and '88 EX500 |profound desire to avoid getting wet.
Re: [HACKERS] GNU readline and BSD license
The Hermit Hacker [EMAIL PROTECTED] writes: someone brought up that when configure runs, it is adding -lreadline to the backend compile, even though that I don't think there is any reason for doing such? There isn't --- configure is just sloppy in that it supplies the same library list for all programs we build. (This might be a fair amount of work to change; never looked at it.) However, I don't see what that has to do with the licensing argument. We stand or fall on psql's use of libreadline, and having useless dependencies from other executables doesn't alter anything that I can see. regards, tom lane
Re: [HACKERS] GNU readline and BSD license
On Fri, 29 Dec 2000, Alfred Perlstein wrote: * The Hermit Hacker [EMAIL PROTECTED] [001229 17:06] wrote: On Fri, 29 Dec 2000, Tom Lane wrote: Alfred Perlstein [EMAIL PROTECTED] writes: My understanding (from the recent discussion) is that Postgresql has certain dependancies on libreadline and won't compile/work without it, Then you're working from a misconception. I think the misconception that he might be working on here is the point someone brought up that when configure runs, it is adding -lreadline to the backend compile, even though that I don't think there is any reason for doing such? I thought psql required libreadline, I'm not sure who said it. Purely optional feature(s) .. if readline isn't found, they aren't enabled ...
Re: [HACKERS] GNU readline and BSD license
The Hermit Hacker writes: Actually, IMHO, the pro to moving to libedit is that we could include it as part of the distribution and make history a *standard* feature History already is a standard feature, you just need to have readline installed. In a world of source code users need to cope with package dependencies, and it's not like readline is the most esoteric package in the world. Gradually adding operating system level things into a package purely to convenience some users is a way to piss of the users at large because you're overriding their operating system setup. If libedit could be used as an alternative to readline depending on your operating system setup then there's nothing wrong with that. NetBSD already went the other way around and made libedit compatible with readline. But given that readline availability during the last five years was apparently just fine I don't understand this discussion at all. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] GNU readline and BSD license
Peter Eisentraut [EMAIL PROTECTED] writes: But given that readline availability during the last five years was apparently just fine I don't understand this discussion at all. Indeed. You could make a better case that we shouldn't be including in our distro the ODBC driver (LGPL) or the several contrib modules that are GPL'd than that psql's optional use of libreadline means we are in violation of GPL. I'm okay with including those things because of the GPL's "mere aggregation" exception --- none of the rest of the system uses any of those modules, so our inclusion of them in the distro looks like mere aggregation to me. But it's a much closer judgment call than the readline situation. regards, tom lane
Re: [HACKERS] GNU readline and BSD license
On Sat, 30 Dec 2000, Peter Eisentraut wrote: The Hermit Hacker writes: Actually, IMHO, the pro to moving to libedit is that we could include it as part of the distribution and make history a *standard* feature History already is a standard feature, you just need to have readline installed. So, history is optional depending on whether or not readline is installed ... if it was standard, it would be enabled regardless of any other dependencies ...
Re: [HACKERS] GNU readline and BSD license
Peter Eisentraut [EMAIL PROTECTED] writes: If libedit could be used as an alternative to readline depending on your operating system setup then there's nothing wrong with that. I have no objection to being able to work with either one, if someone's excited about making that happen. I'd still think it a waste of effort, but as long as it's not my effort I can hardly complain... regards, tom lane
Re: [HACKERS] GNU readline and BSD license
Adam Haberlach [EMAIL PROTECTED] writes: RMS already made a big stink about this, claiming that BeOS's use of an emulation layer to link to some GPL'ed network drivers was enough to force the GPL'ing of the kernel. Did BeOS make distributions that included the GPL'd code? Was the GPL'd code essential for useful use of their system? We can answer "no" to both of those points for Postgres vs. readline, so the Be case doesn't look like precedent to me. regards, tom lane
Re: [HACKERS] GNU readline and BSD license
On Fri, Dec 29, 2000 at 08:46:40PM -0500, Tom Lane wrote: Adam Haberlach [EMAIL PROTECTED] writes: RMS already made a big stink about this, claiming that BeOS's use of an emulation layer to link to some GPL'ed network drivers was enough to force the GPL'ing of the kernel. Did BeOS make distributions that included the GPL'd code? Yes. IIRC (this happened about the time I got here more then two years ago), Be released binary versions of the drivers with the standard distribution as well as source to them as sample code. RMS's main claim was that although the GPL'ed source was released as source, it had to link to the kernel to be useful, and therefore could not be distributed without source to the kernel. Was the GPL'd code essential for useful use of their system? No. -- Adam Haberlach|A cat spends her life conflicted between a [EMAIL PROTECTED] |deep, passionate, and profound desire for http://www.newsnipple.com |fish and an equally deep, passionate, and '88 EX500 |profound desire to avoid getting wet.
Re: [HACKERS] how do i store \0 inside a text attribute?
See bytea, though its presentation format leaves something to be desired IMHO how would someone be expected to store, say, a GIF image in a TOAST text? One would not. A TOASTed bytea is the appropriate column type. thanks -- that's EXACTLY what i needed.
Re: [HACKERS] GNU readline and BSD license
Peter Eisentraut [EMAIL PROTECTED] writes: If there is something functionally wrong with Readline then let's talk about it, but let's not replace it with something because some PHP dude said that RMS said something. ncftp used to be for non-commercial use only and had hooks to be linked against readline. RMS threatened legal action, which caused the developer to change the license to GPL, which was what RMS wanted. So, whatever your opinion of his reasoning and motives, etc., it is undoubtedly RMS's intention to use readline as a point of leverage to get projects to go GPL. Personally, I agree with him. Many don't. Mike.
Re: [HACKERS] GNU readline and BSD license
But given that readline availability during the last five years was apparently just fine I don't understand this discussion at all. I agree with Peter and others on this topic, though the occasional discussion helps to clarify things... - Thomas
Re: [HACKERS] Upper limit on number of buffers?
* mlw [EMAIL PROTECTED] [001224 18:06] wrote: This line works: /usr/local/pgsql/bin/postmaster -N 32 -B 928 -i -S -D/home/postgres/pgdev -o "-F -fs -S 4096" Where as this line: /usr/local/pgsql/bin/postmaster -N 32 -B 1024 -i -S -D/home/postgres/pgdev -o "-F -fs -S 4096" does not. Any ideas? I have 256M of memory, RedHat Linux 7.0, CVS version of Postgres as of a couple days ago. I'm just going to guess that you need to consult your OS's documentation and figure out how to raise the amount of system V shared memory available. I think Alfred is probably correct. I've run into this before myself. See the following link: http://www.postgresql.org/devel-corner/docs/admin/kernel-resources.htm#SYSVI PC The relevant section reads: Linux The default shared memory limit (both SHMMAX and SHMALL) is 32 MB in 2.2 kernels, but it can be changed in the proc file system (without reboot). For example, to allow 128 MB: $ echo 134217728 /proc/sys/kernel/shmall $ echo 134217728 /proc/sys/kernel/shmmax You could put these commands into a script run at boot-time. Other parameters are sufficiently sized for any application. If you want to see for yourself look into /usr/src/linux/include/asm-xxx/shmparam.h and /usr/src/linux/include/linux/sem.h. Hope this helps, Joe
Re: [HACKERS] GNU readline and BSD license
On 29 Dec 2000, Michael Alan Dorman wrote: Peter Eisentraut [EMAIL PROTECTED] writes: If there is something functionally wrong with Readline then let's talk about it, but let's not replace it with something because some PHP dude said that RMS said something. ncftp used to be for non-commercial use only and had hooks to be linked against readline. RMS threatened legal action, which caused the developer to change the license to GPL, which was what RMS wanted. Problem with ncftp was developers distributing binaries commercially which were linked to libreadline. As I said before, postgres doesn't have this problem since neither RPMs nor other binaries do that.
[HACKERS] Possible SELECT bug in 7.0.2
Hello, While working on the next release of Tangram, I have encountered the following problem in version 7.0.2. Given the following tables: Springfield= select version(); version --- PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc 2.95.2 (1 row) Springfield= select * from Person; id | classid --+- 1006 | 6 2006 | 6 3006 | 6 4006 | 6 5006 | 6 (5 rows) Springfield= select * from NP; id | ia_ref | credit | name | firstname | ia_slot | is_ref | partner | age --+++--+---+-++-+- 1006 ||| | Bart | || | 2006 ||| | Lisa | || | 3006 ||| | Maggie| || | 5006 ||| | Marge | || | 4006 ||| | Homer | || | (5 rows) Springfield= select * from s_children; coll | item --+-- 5006 | 3006 5006 | 1006 5006 | 2006 4006 | 1006 4006 | 3006 4006 | 2006 (6 rows) ...I run the following two queries: Springfield= SELECT t4.firstName FROM Person t1, NP t2, s_children tl1001, Person t3, NP t4 WHERE (tl1001.coll = t1.id AND tl1001.item = t3.id) AND t2.id = t1.id AND t4.id = t3.id; firstname --- Bart Bart Maggie Maggie (4 rows) Springfield= SELECT t2.firstName, t4.firstName FROM Person t1, NP t2, s_children tl1001, Person t3, NP t4 WHERE (tl1001.coll = t1.id AND tl1001.item = t3.id) AND t2.id = t1.id AND t4.id = t3.id; firstname | firstname ---+--- Homer | Bart Homer | Lisa Homer | Maggie (3 rows) Both result sets seem wrong; even more bizarre, adding a column in the projection affects the result set. In addition, Tangram's test suite runs flawlessly against Sybase, Mysql, Oracle and Postgres 6.4.2. -- Jean-Louis Leroy http://users.skynet.be/jll
RE: [HACKERS] GEQO status?
I would set Seed per default. Even worse than a bad query path is an unpredictable query path. I see no argument, that a random Seed would buy us anything. This kindof bugs me -- if you leave it stuck at a preset value, it makes it possible to never delve into parts of solution space that have more optimal solutions than the default seed will ever find. Surely a random seed would make the solution better on average over a large number of queries. On the other hand, if the system as a whole is working well, it should not matter what the seed is. - Andrew
Re: [HACKERS] About PQsetClientEncoding(),SET NAMES,and SETCLIENT_ENCODING
We have merged README.mb into the official SGML docs, so the file is gone. Not sure what setup we have for SGML docs in different languages. Even if the Big5 version of README.mb could be included in our SGML docs, I don't think sgml tools could process Big5 without any problem due to the nature of the encoding(probably ok for EUC-TW or UTF-8). What about placing it as doc/README.mb.big5 or whatever? -- Tatsuo Ishii
Re: [HACKERS] Possible SELECT bug in 7.0.2
Jean-Louis Leroy [EMAIL PROTECTED] writes: Both result sets seem wrong; even more bizarre, adding a column in the projection affects the result set. In addition, Tangram's test suite runs flawlessly against Sybase, Mysql, Oracle and Postgres 6.4.2. Seems fishy, but there's not enough info here to diagnose the problem. Does EXPLAIN show nested mergejoin plans for the failing queries? If so, that's a known bug that is fixed in 7.0.3. If not, I'd like to see enough info to reproduce the problem --- a pg_dump database dump and a procedure for reproducing the error after reload would do nicely ... regards, tom lane
Re: [HACKERS] Beta1 starting date?
Since there are going to already be a number of fixes in beta2, I will wait until beta2 to release any RPM's. I am also continuing to get feedback about the packaging -- many thanks to all who are participating in that discussion! I remember the one or two comments I got on the 7.0 RPM changes (from 6.5), and the change is positive this time. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 I would like to make a comment on the stop script in the RPMS. It uses killproc function to kill postmaster. killproc sends SIGTERM to stop postmaster. It's good. However if postmaster won't die (for example, some users are still using psql), it then sends SIGKILL signal to postmaster. This is extremely dangerous since there is no chance for postmaster to clean up resources in this case. I think the signal number should be SIGINT (fast shutdown) or SIGQUIT (immediate shutdown). -- Tatsuo Ishii
