[HACKERS] why I need col. def. list with setof record?
Hello I know so I need to use column definition list when I have SRF function without def of own type. But I don't understand why. In my SRF function I specify all informations about columns? TupleDescInitEntry (tupdesc, 1, idn, INT4OID, -1, 0, false); TupleDescInitEntry (tupdesc, 2, idv, VARCHAROID, -1, 0, false); Why I have to duplicate to? Thank You Pavel Stehule ---(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] [BUG/PATCH] backend crashes during authentication if data/global/pg_pwd is empty
Hi,
on Solaris 9 with PostgreSQL 7.4:
when you
- 'initdb' a fresh database,
- _don't_ set a password for user 'postgres',
- convert the 'trust' lines in data/pg_hba.conf to 'md5' or 'password'
and then try to connect as user 'postgres', the backend crashes in
backend/libpq/hba.c:372:
368 static int
369 user_group_bsearch_cmp(const void *user, const void *list)
370 {
371 /* first node is line number */
372 char *user2 = lfirst(lnext(*(List **) list));
due to 'list' being NULL, which might mean that 'user_sorted' was never
allocated, due to user_length being zero for an missing or empty
global/pg_pwd:
916 /* create sorted lines for binary searching */
917 user_length = length(user_lines);
918 if (user_length)
919 {
920 int i = 0;
921
922 user_sorted = palloc(user_length * sizeof(List *));
I know this is looks like a case of don't do it, then, but since it's a
backend crash, I would suggest the following fix:
--- postgresql-7.4.orig/src/backend/libpq/hba.c 2003-10-25 05:48:46.01000 +0200
+++ postgresql-7.4/src/backend/libpq/hba.c 2003-12-05 15:21:54.03000 +0100
@@ -62,7 +62,7 @@
static List **user_sorted = NULL; /* sorted user list, for bsearch() */
static List **group_sorted = NULL; /* sorted group list, for
*
bsearch() */
-static int user_length;
+static int user_length = 0;
static int group_length;
static List *tokenize_file(FILE *file);
@@ -395,6 +395,10 @@
List **
get_user_line(const char *user)
{
+ /* fail if there is nothing to search in */
+ if ((user_sorted == NULL) || (user_length == 0))
+ return NULL;
+
return (List **) bsearch((void *) user,
(void *) user_sorted,
user_length,
The initialization of user_length might not be necessary.
Best wishes, Mike
PS: This might be related to
http://archives.postgresql.org/pgsql-admin/2003-03/msg00413.php
--
Life is like a fire.DI Michael Wildpaner
Flames which the passer-by forgets.Ph.D. Student
Ashes which the wind scatters.
A man lived. -- Omar Khayyam
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] [BUG/PATCH] backend crashes during authentication if data/global/pg_pwd is empty
Michael Wildpaner [EMAIL PROTECTED] writes: + /* fail if there is nothing to search in */ + if ((user_sorted == NULL) || (user_length == 0)) + return NULL; Hm, Solaris' bsearch() fails on empty input? How bizarre. Easily worked around though --- thanks for the report! I suspect we'd better put a defense in get_group_line as well. It looks like there are no other places at risk in the backend. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [BUG/PATCH] backend crashes during authentication if data/global/pg_pwd is empty
Hm, Solaris' bsearch() fails on empty input? How bizarre. I was skeptical but apparently this is a known bug ... googling turned up a couple of references, eg http://www.opencm.org/pipermail/opencm-dev/2002-July/001077.html regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] 7.4.1 looking good for Wednesday?
As Tom mentioned previous, we are aiming for 7.4.1 on Wednesday of next week ... is anyone sitting on anything that they feel *just has to* be in it? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] 7.4.1 ... slight change of scheduale ...
To accomodate ppls travel scheduales, we are going to move the 7.4.1 release up to Monday, *unless* there is a report before then about something that needs to be fixed first ... we know of nothing outstanding right now ... This means it will be tag'd/bundled on Sunday ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
--On Friday, December 05, 2003 12:47:40 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: To accomodate ppls travel scheduales, we are going to move the 7.4.1 release up to Monday, *unless* there is a report before then about something that needs to be fixed first ... we know of nothing outstanding right now ... Possibly the C error in pg_autovacuum re: time calcs? (see the -performance list from yesterday, conversation between Vivek Khera(sp?) and myself). This means it will be tag'd/bundled on Sunday ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- 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 pgp0.pgp Description: PGP signature
Re: [HACKERS] request for feedback - read-only GUC variables,
Bruce, Marc, Joe: max_function_args - int Shows the maximum number of function arguments max_index_keys - int Shows the maximum number of index keys Have we decoupled these two variables? Last I checked, their values still had to be identical. If they have not been decoupled and won't be in the forseable future, why bother with 2 variables? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
On Fri, 5 Dec 2003, Peter Eisentraut wrote: Marc G. Fournier writes: To accomodate ppls travel scheduales, we are going to move the 7.4.1 release up to Monday, *unless* there is a report before then about something that needs to be fixed first ... we know of nothing outstanding right now ... A bug in the information schema concerning the bit types must be fixed. Does anyone have a patch for this? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Marc G. Fournier writes: To accomodate ppls travel scheduales, we are going to move the 7.4.1 release up to Monday, *unless* there is a report before then about something that needs to be fixed first ... we know of nothing outstanding right now ... A bug in the information schema concerning the bit types must be fixed. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Marc G. Fournier wrote: To accomodate ppls travel scheduales, we are going to move the 7.4.1 release up to Monday, *unless* there is a report before then about something that needs to be fixed first ... we know of nothing outstanding right now ... This means it will be tag'd/bundled on Sunday ... I've got one I've been conversing about off-list with Tom. Fix for bytea LIKE. I think I'm just about done with the fix. If so, I'll commit tonight or tomorrow morning. Not sure if it's worth holding the release for though. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] request for feedback - read-only GUC variables,
Josh Berkus wrote: max_function_args - int Shows the maximum number of function arguments max_index_keys - int Shows the maximum number of index keys Have we decoupled these two variables? Last I checked, their values still had to be identical. If they have not been decoupled and won't be in the forseable future, why bother with 2 variables? Their values are still the same, but Tom suggested we not couple them inextricably by giving users access to them as one variable. Joe ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Proposed Query Planner TODO items
PG Folks, What follows are a couple of proposed TODO items to make up for some of the places our planner is weak compared to other leading databases. Particularly, I'm personally concerned that as of 7.4.0 we would fail the TPC benchmark even if someone sponsored us for it (see Issue #2 below). I freely admit that I don't have the skill to implement either of these; instead, I want them on the TODO list just so we don't lose track of them, and just in case some new brilliant coder jumps into our community looking for something to do. 1) MAINTAIN CORROLARY STATS ON FORIEGN KEYS Summary: Keep correspondance statistics between FK columns. Description: One of the areas of ongoing planner estimation problems estimation of cross-table correspondence of column values. Indeed, as late a 7.2.4 the WHERE EXISTS code just estimated a flat 50%. While it would be practically impossible to maintain statistics between all columns in a database that might possibly be compared, there is one class of cross-table column comparisons which is both used heavily and is readily identifiable: foriegn keys. My proposal is to keep statistics on the correlation of values between the key and foriegn key values in order to arrive at better estimates. Adapting the newly committed pg_indexstats to track this as well seems to me to be the easiest method, but I'll admit to not really understanding Manfried's code. NOTE: This suggestion was dicussed on Hackers early last summer and received general approval but somehow never ended up on the TODO list. 2) DEVELOP BETTER PLANS FOR OR GROUP QUERIES Summary: Currently, queries with complex or group criteria get devolved by the planner into canonical and-or filters resulting in very poor execution on large data sets. We should find better ways of dealing with these queries, for example UNIONing. Description: While helping OSDL with their derivative TPC-R benchmark, we ran into a query (#19) which took several hours to complete on PostgreSQL. It was in the general form: SELECT t1.a, t2.b FROM t1, t2 WHERE t1.a = t2.a AND ( ( t1.c = x AND t1.f IN (m, n, o) AND t2.d = v AND t2.e BETWEEN j AND k ) OR ( t1.c = y AND t1.f IN (n, o, p) AND t2.d = v AND t2.e BETWEEN k AND h ) OR ( t1.c = z AND t1.f IN (p, q) AND t2.d = w AND t2.e BETWEEN k AND h ) ) The reason why this query is included in the TPC benchmarks is the reason I've run into problems with similar querys before; it is the kind of query produced by many 3rd-party decision-support and reporting applications. Its distinguishing feature is the same thing which gives PG indigestion; the distinct OR groups with a complex set of criteria for each. Or planner's approach to this sort of query is to devolve the criteria into a 3-page long set of canonical and-or filters, and seq scan the entire underlying data set. This is fine if the data set is small, but if it's several times the size of RAM, a full-table seq scan is fatal, as it is for TPC-R which seems specifically designed to test for this kind of failure. One solution which suggests itself is that the following query form runs in a couple of seconds: SELECT t1.a, t2.b FROM t1, t2 WHERE t1.a = t2.a AND t1.c = x AND t1.f IN (m, n, o) AND t2.d = v AND t2.e BETWEEN j AND k UNION ALL SELECT t1.a, t2.b FROM t1, t2 WHERE t1.a = t2.a AND t1.c = y AND t1.f IN (n, o, p) AND t2.d = v AND t2.e BETWEEN k AND h UNION ALL SELECT t1.a, t2.b FROM t1, t2 AND t1.c = z AND t1.f IN (p, q) AND t2.d = w AND t2.e BETWEEN k AND h So the trick would be teaching the planner to: a) recognize an or group query when it sees one; b) break down that query into a multi-part union and estimate the cost However, I'm sure there are other possible solutions. Oracle and MSSQL have solved this particular query problem; anybody know how they do it? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Postgres 7.3.5 and count('x')
Hello,
It appears that the count('x') will no longer work without a type
cast. Is this on purpose? I've already modified my code to use
count(*) instead, but I decided to mention it anyway.
warehouse=# select count('x') ;
ERROR: cannot accept a value of type any
warehouse=# select count('x'::text) ;
count
---
1
(1 row)
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Examining the output of: ldd `which postgres`
[Up front: yes, I'm following up to a post that's nearly three months old. I can't find any more recent discussion of this issue.] [EMAIL PROTECTED] (Tom Lane) writes: (Of course, if you can show that there's a significant penalty in backend launch time from having useless shlibs linked in, I'd get more excited about it...) How about failure to start at all, when an otherwise-unnecessary shared library is removed from the system? For example, all of our boxes have readline as a non-shared library...except for one. At some point, a newer, non-shared version was installed on this particular machine, and the shared lib was removed. The next time the machine was rebooted, some months later, Postgres wouldn't start due to the missing dependency. I've been re-linking the backend by hand without readline and ncurses after compiling a new version, and just not worrying about the rest of the tools. Today after finding this thread, I decided to see what could be removed. I wrote a short combo of shell and perl to brute-force relink everything in the pgsql/bin directory, to see what could be removed. Boy, was I surprised: Relinking ./src/bin/scripts/clusterdb Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm Relinking ./src/bin/scripts/createdb Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm Relinking ./src/bin/scripts/createlang Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm Relinking ./src/bin/scripts/createuser Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm Relinking ./src/bin/scripts/dropdb Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm Relinking ./src/bin/scripts/droplang Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm Relinking ./src/bin/scripts/dropuser Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm Relinking ./src/interfaces/ecpg/preproc/ecpg Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm Relinking ./src/bin/pg_controldata/pg_controldata Successfully removed: -lpq -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm Relinking ./src/bin/pg_dump/pg_dump Successfully removed: -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm Relinking ./src/bin/pg_dump/pg_dumpall Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm Relinking ./src/bin/pg_encoding/pg_encoding Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm -lpgport Relinking ./src/bin/pg_id/pg_id Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm -lpgport Relinking ./src/bin/pg_resetxlog/pg_resetxlog Successfully removed: -lpq -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm Relinking ./src/bin/pg_dump/pg_restore Successfully removed: -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm Relinking ./src/backend/postgres Successfully removed: -lz -lreadline -lncurses -lresolv -lnsl Relinking ./src/bin/psql/psql Successfully removed: -lz -lcrypt -lresolv -lnsl -ldl -lm Relinking ./src/bin/scripts/vacuumdb Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm (Code on request to anyone who wants it, but warning: it's stupid.) It might just be me, but it seems like psql starts up faster without the extraneous libs. It's always fast, but seems instantaneous now. I don't know...it seems crazy, but maybe something like my tool could be included, if you want to relink your setup down to the minimum necessary libraries? Todd -- Todd R. Eigenschink TEK Interactive Group, Inc. [EMAIL PROTECTED] http://www.tekinteractive.com/ System Administrator(260) 459-2521 ---(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] *sigh*
The count(*) information can be revisioned too, am I wrong ? I'm able to create a trigger that store the count(*) information in a special table, why not implement the same in a way builded in ? Then every insert or delete would have to lock that count. Nobody else would be able to insert or delete any records until you either commit or roll back. That would lead to much lower concurrency, much more contention for locks, and tons of deadlocks. What about queueing all these updates for a separate low-priority thread? The thread would be the only one with access to update this field. -- Randolf Richardson - [EMAIL PROTECTED] Vancouver, British Columbia, Canada Please do not eMail me directly when responding to my postings in the newsgroups. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Something's not (de)compressing right
http://archives.postgresql.org/pgsql-hackers/2000-07/msg00483.php
I'm having this same problem with postgresql 7.3.4. Easy to reproduce by
running an 'INSERT' query. Here is some of the debugging info if I break
near the beginning of the pglz_decompress function:
(gdb) p dend
$1 = (unsigned char *) 0xc47f0602 Address 0xc47f0602 out of bounds
(gdb) p dp
$2 = (unsigned char *) 0xb605153c
(gdb) p *source
$3 = {varsize = 1316614350, rawsize = 2328}
(gdb) up
#1 0x0807c0b0 in heap_tuple_untoast_attr (attr=0xb6051534)
at tuptoaster.c:151
151 pglz_decompress((PGLZ_Header *) attr,
VARATT_DATA(result));
(gdb) p *attr
$4 = {va_header = 1316614350, va_content = {va_compressed = {
va_rawsize = 2328, va_data = }, va_external = {va_rawsize = 2328,
va_extsize = 786432, va_valueid = 1048579,
va_toastrelid = 1316614344}, va_data = \030}}
Ideas? Any more information I can provide? Looks like the bad value is
coming in through 'dend', but I don't understand VARATT_SIZE well enough
to know where the bad value is coming from.
Ciao,
-- Elliot
The mark of an immature man is that he wants to die nobly for a cause,
while the mark of a mature man is that he wants to live humbly for
one.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] postgresql-7.4 make error: tuptoaster.c: In function `toast_delete_datum'
im not sure if this is the correct mailing list, please correct me if it is not. my gcc is version 3.2, configure runs fine i deativated readline-support...but this error occours: gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -D_GNU_SOURCE -c -o tuptoaster.o tuptoaster.c tuptoaster.c: In function `toast_delete_datum': tuptoaster.c:973: `F_OIDEQ' undeclared (first use in this function) any ideas ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] [fwd: [GENERAL] Domains and function]
I did not get any response to this question on general so I am forwarding it to hackers. Thanks, elein - Forwarded message from elein [EMAIL PROTECTED] - Date: Sat, 29 Nov 2003 14:11:20 -0800 From: elein [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: elein [EMAIL PROTECTED] Subject: [GENERAL] Domains and function Mail-Followup-To: [EMAIL PROTECTED] User-Agent: Mutt/1.3.22.1i Precedence: bulk I can create a function with a domain and define it to return a domain. The parameter is checked to see if it qualifies in the constraint of the domain, however, the return value is not. Is this a bug? Or is the author of the function responsible for re-inforcing the constraint at runtime? This is the test case in 7.4: =# create domain one2hundred AS integer -#DEFAULT '1' CONSTRAINT email_domain check( VALUE 0 AND VALUE =100 ); CREATE DOMAIN =# =# create function gb52_add( one2hundred ) -# returns one2hundred as -# ' '# BEGIN '#RETURN $1 + 10; '# END; '# ' language 'plpgsql'; CREATE FUNCTION =# =# select gb52_add( 80); gb52_add -- 90 (1 row) =# select gb52_add( 100); gb52_add -- 110 (1 row) =# select gb52_add( 90); gb52_add -- 100 (1 row) =# select gb52_add( 91); gb52_add -- 101 (1 row) =# select gb52_add( 191); ERROR: value for domain one2hundred violates check constraint email_domain [EMAIL PROTECTED]Varlena, LLCwww.varlena.com PostgreSQL Consulting, Support Training PostgreSQL General Bits http://www.varlena.com/GeneralBits/ = I have always depended on the [QA] of strangers. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match - End forwarded message - ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Proposed Query Planner TODO items
John, SELECT t1.a, t2.b FROM t1, t2 WHERE t1.a = t2.a AND t1.c = x AND t1.f IN (m, n, o) AND t2.d = v AND t2.e BETWEEN j AND k UNION ALL Shouldn't that be UNION instead of UNION ALL? You don't want duplicate rows, if i'm not mistaken. Yes, you're correct; I copied UNION ALL from a test case which was not generic. In general, one would want UNION. -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Proposed Query Planner TODO items
I know Oracle is capable of producing the UNION plan. but I don't know if that's the only option. I'm curious what indexes the rewritten union-based query used. Josh Berkus [EMAIL PROTECTED] writes: SELECT t1.a, t2.b FROM t1, t2 WHERE t1.a = t2.a AND ( ( t1.c = x AND t1.f IN (m, n, o) AND t2.d = v AND t2.e BETWEEN j AND k ) OR ( t1.c = y AND t1.f IN (n, o, p) AND t2.d = v AND t2.e BETWEEN k AND h ) OR ( t1.c = z AND t1.f IN (p, q) AND t2.d = w AND t2.e BETWEEN k AND h ) ) In this case it seems like it might be possible to look for a covering set that is guaranteed to include all the records and doesn't include any ORs. If that covering set can be scanned quickly then the complex conditions could be tested on the resulting records individually. In this case it would be something like select t1.a,t2.b from t1,t2 where t1.a = t2.a and (t1.c in (x,y,z) and t1.f in (m,n,o,p,q) and t2.d in (v,w) and t2.e between min(j,k) and max(k,h) ) and ( the above constraints...) It seems like it would be a lot of work and only help in narrow cases though. -- greg ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [BUG/PATCH] backend crashes during authentication if
Hi,
On Fri, 5 Dec 2003, Tom Lane wrote:
Hm, Solaris' bsearch() fails on empty input? How bizarre.
I was skeptical but apparently this is a known bug ...
googling turned up a couple of references, eg
http://www.opencm.org/pipermail/opencm-dev/2002-July/001077.html
in defense of Solaris' bsearch it should be said that it only breaks if
one passes NULL as the array base, a decidedly undefined (and unfriendly)
case. Passing an array with zero elements works as advertised. Btw, the
same happens on IRIX.
Best wishes, Mike
PS: A little program to demonstrate this: array with elements, empty
array, NULL pointer as base:
#include stdio.h
#include stdlib.h
#include string.h
char strings[][4] = { abc, efg, hij, klm };
typedef int (*cmp_t)(const void*, const void*);
int main(int argc, char**argv) {
char *s, *term = hij;
s = bsearch(term, strings, sizeof(strings)/sizeof(char[4]),
sizeof(char*), (cmp_t) strcmp);
fprintf(stderr, 1: %s\n, (s != NULL) ? s : not found);
s = bsearch(term, strings, 0, sizeof(char*), (cmp_t) strcmp);
fprintf(stderr, 2: %s\n, (s != NULL) ? s : not found);
s = bsearch(term, NULL, 0, sizeof(char*), (cmp_t) strcmp);
fprintf(stderr, 3: %s\n, (s != NULL) ? s : not found);
return 0;
}
Results:
$ ./a.out # Solaris 9
1: hij
2: not found
Segmentation Fault (core dumped)
$ ./a.out # IRIX 6.5
1: hij
2: not found
Segmentation fault (core dumped)
$ ./a.out # Linux with glibc 2.2.5
1: hij
2: not found
3: not found
$ ./a.out # OpenBSD 3.2
1: hij
2: not found
3: not found
--
Life is like a fire.DI Michael Wildpaner
Flames which the passer-by forgets.Ph.D. Student
Ashes which the wind scatters.
A man lived. -- Omar Khayyam
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] bytea, index and like operator again and detailed report
Alvar Freude wrote:
while changing a column from base255 encoded text (all except null byte) to
bytea, I found the following bug in Postgresql's LIKE operator with indexes
(it follows a more detailed description then my old mails in -bugs and
- -general, including the proof of the bug):
Please try the attached patch and let me know how it works for you. It
is against cvs HEAD, but should apply OK to 7.4.
Thanks,
Joe
Index: src/backend/utils/adt/selfuncs.c
===
RCS file: /opt/src/cvs/pgsql-server/src/backend/utils/adt/selfuncs.c,v
retrieving revision 1.149
diff -c -r1.149 selfuncs.c
*** src/backend/utils/adt/selfuncs.c29 Nov 2003 19:51:59 - 1.149
--- src/backend/utils/adt/selfuncs.c5 Dec 2003 19:42:39 -
***
*** 184,189
--- 184,190
static Selectivity pattern_selectivity(Const *patt, Pattern_Type ptype);
static Datum string_to_datum(const char *str, Oid datatype);
static Const *string_to_const(const char *str, Oid datatype);
+ static Const *string_to_bytea_const(const char *str, size_t str_len);
/*
***
*** 3135,3154
}
else
{
! patt = DatumGetCString(DirectFunctionCall1(byteaout,
patt_const-constvalue));
! pattlen = toast_raw_datum_size(patt_const-constvalue) - VARHDRSZ;
}
match = palloc(pattlen + 1);
match_pos = 0;
-
for (pos = 0; pos pattlen; pos++)
{
/* % and _ are wildcard characters in LIKE */
if (patt[pos] == '%' ||
patt[pos] == '_')
break;
! /* Backslash quotes the next character */
if (patt[pos] == '\\')
{
pos++;
--- 3136,3166
}
else
{
! bytea *bstr = DatumGetByteaP(patt_const-constvalue);
!
! pattlen = VARSIZE(bstr) - VARHDRSZ;
! if (pattlen 0)
! {
! patt = (char *) palloc(pattlen);
! memcpy(patt, VARDATA(bstr), pattlen);
! }
! else
! patt = NULL;
!
! if ((Pointer) bstr != DatumGetPointer(patt_const-constvalue))
! pfree(bstr);
}
match = palloc(pattlen + 1);
match_pos = 0;
for (pos = 0; pos pattlen; pos++)
{
/* % and _ are wildcard characters in LIKE */
if (patt[pos] == '%' ||
patt[pos] == '_')
break;
!
! /* Backslash escapes the next character */
if (patt[pos] == '\\')
{
pos++;
***
*** 3174,3183
match[match_pos] = '\0';
rest = patt[pos];
! *prefix_const = string_to_const(match, typeid);
! *rest_const = string_to_const(rest, typeid);
! pfree(patt);
pfree(match);
/* in LIKE, an empty pattern is an exact match! */
--- 3186,3204
match[match_pos] = '\0';
rest = patt[pos];
! if (typeid != BYTEAOID)
! {
! *prefix_const = string_to_const(match, typeid);
! *rest_const = string_to_const(rest, typeid);
! }
! else
! {
! *prefix_const = string_to_bytea_const(match, match_pos);
! *rest_const = string_to_bytea_const(rest, pattlen - match_pos);
! }
! if (patt != NULL)
! pfree(patt);
pfree(match);
/* in LIKE, an empty pattern is an exact match! */
***
*** 3500,3508
}
else
{
! patt = DatumGetCString(DirectFunctionCall1(byteaout,
patt_const-constvalue));
! pattlen = toast_raw_datum_size(patt_const-constvalue) - VARHDRSZ;
}
/* Skip any leading %; it's already factored into initial sel */
start = (*patt == '%') ? 1 : 0;
--- 3521,3542
}
else
{
! bytea *bstr = DatumGetByteaP(patt_const-constvalue);
!
! pattlen = VARSIZE(bstr) - VARHDRSZ;
! if (pattlen 0)
! {
! patt = (char *) palloc(pattlen);
! memcpy(patt, VARDATA(bstr), pattlen);
! }
! else
! patt = NULL;
!
! if ((Pointer) bstr != DatumGetPointer(patt_const-constvalue))
! pfree(bstr);
}
+ /* patt should never be NULL in practice */
+ Assert(patt != NULL);
/* Skip any leading %; it's already factored into initial sel */
start = (*patt == '%') ? 1 : 0;
***
*** 3693,3700
/*
* Try to generate a string greater than the given string or any
! * string it is a prefix of. If successful,
Re: [HACKERS] postgresql-7.4 make error: tuptoaster.c: In function
On Fri, 2 Jan 2004, julius wrote:
im not sure if this is the correct mailing list, please correct me if it is not.
my gcc is version 3.2, configure runs fine i deativated readline-support...but this
error occours:
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../../src/include -D_GNU_SOURCE -c -o tuptoaster.o tuptoaster.c
tuptoaster.c: In function `toast_delete_datum':
tuptoaster.c:973: `F_OIDEQ' undeclared (first use in this function)
I ran into the same thing when working with RPMs and the tarball(s).
This happened in a vserver (http://www.linux-vserver.org/) not in the main
server. No solution at this time. In fact I caved and used the pre-built
RPMs. :-) Good luck.
Rod
--
Open Source Software - You usually get more than you pay for...
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] bytea, index and like operator again and detailed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Joe, - -- Joe Conway [EMAIL PROTECTED] wrote: Please try the attached patch and let me know how it works for you. It is against cvs HEAD, but should apply OK to 7.4. has this about one week time? I travel on monday to Geneva (World Summit on the Information Society) and have a lot to prepare ... :-( I'll make a report when I have some minutes (or hours ;) ) ... Ciao Alvar - -- ** Alvar C.H. Freude -- http://alvar.a-blast.org/ -- http://odem.org/ ** Berufsverbot? http://odem.org/aktuelles/staatsanwalt.de.html ** ODEM.org-Tour: http://tour.odem.org/ ** Informationsgesellschaft: http://www.wsis-koordinierungskreis.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/0RU8OndlH63J86wRAkKIAKDA6iRUyFg3qm7GRrUs9OnlhozVKwCfSVmk jI5lGQ0vQLj22qsMCTLpn4I= =au3Z -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Marc G. Fournier wrote: A bug in the information schema concerning the bit types must be fixed. Does anyone have a patch for this? I suppose not, but it's being worked on. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] bytea, index and like operator again and detailed report
Alvar Freude wrote: has this about one week time? I travel on monday to Geneva (World Summit on the Information Society) and have a lot to prepare ... :-( I'll make a report when I have some minutes (or hours ;) ) ... Well, 7.4.1 will be bundled up for release on Sunday, so it would be ideal to get some feedback sooner if possible. Joe ---(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] 7.4.1 ... slight change of scheduale ...
On Sat, 6 Dec 2003, Peter Eisentraut wrote: Marc G. Fournier wrote: A bug in the information schema concerning the bit types must be fixed. Does anyone have a patch for this? I suppose not, but it's being worked on. Is that the one that Joe just mentioned workign on? about BYTEA? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] bytea, index and like operator again and detailed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Joe Conway [EMAIL PROTECTED] wrote: Well, 7.4.1 will be bundled up for release on Sunday, so it would be ideal to get some feedback sooner if possible. this is a good argument ... ;) I'll try to check it ... Ciao Alvar - -- ** Alvar C.H. Freude -- http://alvar.a-blast.org/ -- http://odem.org/ ** Berufsverbot? http://odem.org/aktuelles/staatsanwalt.de.html ** ODEM.org-Tour: http://tour.odem.org/ ** Informationsgesellschaft: http://www.wsis-koordinierungskreis.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/0S1jOndlH63J86wRAkMiAJ4xa9t4OR+Oif/IvUEMgZ5Yl52lpwCgnboU bIyeU+IwfK3C34JltRmBuoU= =zHKC -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Marc G. Fournier wrote: On Sat, 6 Dec 2003, Peter Eisentraut wrote: I suppose not, but it's being worked on. Is that the one that Joe just mentioned workign on? about BYTEA? I don't think so. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] bytea, index and like operator again and detailed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, - -- Joe Conway [EMAIL PROTECTED] wrote: Please try the attached patch and let me know how it works for you. It is against cvs HEAD, but should apply OK to 7.4. so, I checked it with my database. It looks good, all checks I made are OK. I realised, that converting my text column to bytea is much faster then before: UPDATE forum_gtree SET gid2 = (decode(replace(gid, '\\', ''), 'escape')); This may be because some other side effects (but it's the same machine and same disc, same partition), but also perhaps some changes in the patch ... MANY THANKS! When I'm back from WSIS I make the next try to change my application from Base255-text to bytea ;-) Ciao Alvar - -- ** Alvar C.H. Freude -- http://alvar.a-blast.org/ -- http://odem.org/ ** Berufsverbot? http://odem.org/aktuelles/staatsanwalt.de.html ** ODEM.org-Tour: http://tour.odem.org/ ** Informationsgesellschaft: http://www.wsis-koordinierungskreis.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/0Tg6OndlH63J86wRAiLfAJ98wLJeeyEuFXG07Pa7ba/jM7LzxQCgzWa1 RGv3FtQ8JP/MZjCWuqbdnsY= =U9Ng -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Peter Eisentraut [EMAIL PROTECTED] writes: A bug in the information schema concerning the bit types must be fixed. Does anyone have a patch for this? I suppose not, but it's being worked on. What's the bug exactly? Is it worth delaying the release for? Given that Bruce is out of town now and I'll be out of town later in the week, we are probably talking about slipping 7.4.1 a full week (to Monday next) if we can't wrap it Sunday or Monday. I don't have any strong compulsion to release 7.4.1 now --- if there's good stuff in the pipeline we could certainly wait a week. But you didn't say just what this bug is ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] request for feedback - read-only GUC variables,
Joe Conway [EMAIL PROTECTED] writes: Josh Berkus wrote: Have we decoupled these two variables? Their values are still the same, but Tom suggested we not couple them inextricably by giving users access to them as one variable. The only reason they are the same is that pg_proc.proargtypes and pg_index.indclass use the same fixed-length datatype, oidvector, and so FUNC_MAX_ARGS and INDEX_MAX_KEYS must both equal the size of this array type. We could decouple them if we felt like it, by introducing a second oidvector-ish datatype for one table or the other. While I don't see any particular reason to do so, it could happen that we want to sometime in the future. If we publicize to users that there is only one variable determining both limits, it'd be a lot harder to do anything. Basically the point is that the backend code is careful to use FUNC_MAX_ARGS or INDEX_MAX_KEYS as appropriate, and we shouldn't throw away that distinction at the user level. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Postgres 7.3.5 and count('x')
[EMAIL PROTECTED] (Edwin S. Ramirez) writes:
It appears that the count('x') will no longer work without a type
cast. Is this on purpose?
warehouse=# select count('x') ;
ERROR: cannot accept a value of type any
Hm, that query seems like it should be legal. (You get the same
from select count('x') from some_table, so it's not the lack of
a table to iterate over that's the issue.)
The most direct fix is probably to make any_in() return some random
value (may as well be ((Datum) 0)) instead of producing an error.
I can't offhand see any real downside to doing so, but I'm a little
worried that it might introduce a gap in the type system. Can anyone
see a reason not to do that? Or a better fix for Edwin's complaint?
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] postgresql-7.4 make error: tuptoaster.c: In function
Roderick A. Anderson [EMAIL PROTECTED] writes: tuptoaster.c: In function `toast_delete_datum': tuptoaster.c:973: `F_OIDEQ' undeclared (first use in this function) I ran into the same thing when working with RPMs and the tarball(s). This suggests that the shell script src/backend/utils/Gen_fmgrtab.sh failed to make a correct fmgroids.h file (probably it emitted an empty file instead). We have seen one or two reports of such failures in the past, but AFAIR they boiled down to lack of awk or sed. Seems unlikely that you'd be lacking those tools on a standard Linux installation. Can you dig into the script and see what's going wrong? And why the script isn't noticing? regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Call for pg_dump testing
I have committed some fairly wide-ranging revisions to pg_dump to make it dump database objects in a safe order according to the dependency information available from pg_depend. While I know that I have fixed a lot of previously-broken cases, it's hardly unlikely that I've broken some things too. Please give it a try if you can. CVS-tip pg_dump should be fully compatible with 7.4 installations, and reasonably compatible with 7.3 servers as well (but its output is unlikely to load into pre-7.3 servers because of syntax changes). If anyone wants to try using this pg_dump to dump from 7.2 or before and reload into 7.4-or-CVS-tip, I'd also be interested to hear how well that works. When dumping from a pre-7.3 server there is no pg_depend info available, so pg_dump is on its own to guess at a reasonable dump order. I do not promise that pg_dump is any better than before in this situation, but if it's gotten worse then I'd like to know about it. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] OpenFTS-perl-0.35 released
OpenFTS development team is proud to announce release of OpenFTS 0.35 perl version - open-source full text search engine for PostgreSQL. Download from http://sourceforge.net/project/showfiles.php?group_id=30968 Major changes: * use contrib/tsearch2 * ispell dictionary supports compound words (sponsored by ABC Startsiden) * use ranking function from contrib/tsearch2 OpenFTS Web site - http://openfts.sourceforge.net/ 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 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
