Re: [BUGS] BUG #2735: DEBUG: Error 2769: Custom Action GetAvailableLocales did not close 1 MSIHANDLEs
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Emil J. > Sent: den 4 november 2006 10:46 > To: pgsql-bugs@postgresql.org > Subject: [BUGS] BUG #2735: DEBUG: Error 2769: Custom Action > GetAvailableLocales did not close 1 MSIHANDLEs > > > The following bug has been logged online: > > Bug reference: 2735 > Logged by: Emil J. > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.5, 8.1.4 > Operating system: Windows XP Pro SP2 > Description:DEBUG: Error 2769: Custom Action > GetAvailableLocales > did not close 1 MSIHANDLEs > Details: > > When i run postgresql-8.1.msi, "Welcome" window appear. I > click on "Start" > button. Nothing happened. > > I read this: http://www.postgresql.org/docs/faqs.FAQ_windows.html#3.1 > I don't have antivir, don't have firewall. You were likely at the correct FAQ and the correct question, but too early in it. Specifiaclly, the part about cygwin seems it could apply. Either that, or some other DLL is hanging upon loading - check what kind of perl/python/tcl DLLs you have in the system PATH and try to temporarily remove them. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #2740: gcc bug on intel mac with postgresql -O3 optimized build
The following bug has been logged online: Bug reference: 2740 Logged by: Alon Goldshuv Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.5 Operating system: Mac OSX intel Description:gcc bug on intel mac with postgresql -O3 optimized build Details: I don't know if this is a known issue already and was reported previously. This is a gcc bug, and *not a postgresql bug*, but it affects query results and should be of interest to intel mac pg users. Regression tests showed wrong output for a query in the 'select_views' test *only on intel mac*. Query is: SELECT * FROM street ORDER BY 1. We narrowed it down to the '?#' operator which returns wrong results (in the 'street' view it is actually a user defined 'path ## path' operator that is based on the 'path ?# path' logic). A simple way to reproduce without creating tables and running multi row result queries is the following 1 line statement: select path '((-122.1,37.3),(-122.2,37.5),(-122,37.5))' ?# path '((-122.1697,37.375),(-122.1681,37.383))'; This statement should always return 'false'. However on the tested intel mac platform it returned 'true'. We ended up tracing it all the way to gcc. Turns out that the gcc version we were using had a bug in one of the optimization flags that get included with -O3, i believe it was function inlining. When compiling with -O2 or lower the query would return the correct result. We upgraded the xcode tools version with the latest - Xcode 2.4.1 released 31Oct2006, and that fixed the bug. compiler with -O3 bug: i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250) updated bug free gcc: i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367) regards, Alon. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2694: Memory allocation error when selecting array
Joe Conway <[EMAIL PROTECTED]> writes:
> ... But as I've opined before, all of this seems to me to be much cleaner if
> arrays were always one-dimensional, and array elements could also be
> nested arrays (per SQL 2003). If we said that the cardinality of the
> nested array is an integral part of the datatype, then I think you would
> have:
> regression=# select array['{}'::text[], '{a,b,c}'::text[]];
> ERROR: nested arrays must have array expressions with matching
> dimensions
> regression=# select array[NULL::text[], '{a,b,c}'::text[]];
> array
>---
> {NULL, {a,b,c}}
>(1 row)
> So maybe this is the behavior we should shoot for now?
Perhaps that's something to think about for 8.3, but it's clearly
infeasible for 8.2, to say nothing of the back branches. What I've
just committed does this:
* if all inputs are empty arrays, return an empty array (instead of failing)
* if mix of empty and nonempty arrays, raise error (same as before)
The case of NULL subarrays is a bit weird. In the back branches the
ARRAY[] construct was strict and would return a NULL array if any input
was NULL; I think it would be a bad idea to change that. The HEAD code
was simply skipping over NULL subarrays, which seemed like a good idea
at the time but on reflection is not so hot. What I've done is to make
it treat NULL subarrays as if they were empty subarrays.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2739: INTERSECT ALL not working
The following bug has been logged online: Bug reference: 2739 Logged by: Mason Hale Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.5 Operating system: GNU/Linux 2.6.9-42.0.3.ELsmp Description:INTERSECT ALL not working Details: 'INTERSECT ALL' does not return duplicate rows in a query. The query below should return 10 rows, but it returns 5 rows on my system: ( SELECT tablename FROM pg_tables LIMIT 5 ) INTERSECT ALL ( ( SELECT tablename FROM pg_tables LIMIT 5 ) UNION ALL ( SELECT tablename FROM pg_tables LIMIT 5 ) ) Note, the above is a simplied query meant to demonstrate the problem. This same behavior occurs (and was discovered) in real-world situations with user-defined tables. This is nearly a deal-stopper for our application. Please reply to let me know the status of this report. Thanks, Mason Hale ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2739: INTERSECT ALL not working
"Mason Hale" <[EMAIL PROTECTED]> writes: > The query below should return 10 rows, Not by my reading of the spec. SQL92 7.10 saith: b) If a set operator is specified, then the result of applying the set operator is a table containing the following rows: i) Let R be a row that is a duplicate of some row in T1 or of some row in T2 or both. Let m be the number of duplicates of R in T1 and let n be the number of duplicates of R in T2, where m >= 0 and n >= 0. ... iii) If ALL is specified, then ... 3) If INTERSECT is specified, then the number of duplicates of R that T contains is the minimum of m and n. You have m = 1, n = 2 for each distinct row at the INTERSECT step, ergo you get one copy out. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2739: INTERSECT ALL not working
Tom -Many thanks for the quick reply. I feel honored to receive email from you after seeing your name so many times in my web searches on Postgres topics.That's not how I understood INTERSECT ALL to work. But it's the clear the spec is right and my understanding is wrong. This is not a bug.Unfortunately the INTERSECT ALL as spec'd and implemented doesn't quite give me what I need. So back to the drawing board for me...best regards,Mason On 11/6/06, Tom Lane <[EMAIL PROTECTED]> wrote: "Mason Hale" <[EMAIL PROTECTED]> writes:> The query below should return 10 rows,Not by my reading of the spec. SQL92 7.10 saith:b) If a set operator is specified, then the result of applying the set operator is a table containing the following rows: i) Let R be a row that is a duplicate of some row in T1 or of some row in T2 or both. Let m be the number of duplicates of R in T1 and let n be the number of duplicates of R in T2, where m >= 0 and n >= 0iii) If ALL is specified, then... 3) If INTERSECT is specified, then the number of duplicates of R that T contains is the minimum of m and n.You have m = 1, n = 2 for each distinct row at the INTERSECT step,ergo you get one copy out.regards, tom lane
Re: [BUGS] Operator Classes and ANALYZE
On Fri, 2006-11-03 at 15:16 -0700, Rusty Conover wrote: > It doesn't appear that ANALYZE uses the specified operator class for > producing statistics on an index when that operator class is not the > default for the data type. This appears to be leading to poor query > planning. > For speed of indexing a few million urls I'm indexing them with a > custom data type. The data type aptly named "urlhash" has: Have you read the CREATE TYPE man page, specifically with regard to the analyze_function clause? Basically, if you want anything different, you have to write an analysis function yourself. This is what PostGIS (www.postgis.org) does, if you want to look for specific code examples. ANALYZE collects stats for tables, not indexes, using the default operator class for the datatype. So even though you've clearly specified an opclass for the index, no stats will be collected using it. Alternatively, perhaps you have fallen foul of this situation? /* * Can't analyze if the opclass uses a storage type * different from the expression result type. We'd get * confused because the type shown in pg_attribute for * the index column doesn't match what we are getting * from the expression. Perhaps this can be fixed * someday, but for now, punt. */ It's in the analyze.c code, but not in the docs. Be interested in a full report of your research, once you're done. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: 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: [BUGS] Operator Classes and ANALYZE
On Nov 6, 2006, at 1:53 PM, Simon Riggs wrote: On Fri, 2006-11-03 at 15:16 -0700, Rusty Conover wrote: It doesn't appear that ANALYZE uses the specified operator class for producing statistics on an index when that operator class is not the default for the data type. This appears to be leading to poor query planning. For speed of indexing a few million urls I'm indexing them with a custom data type. The data type aptly named "urlhash" has: Have you read the CREATE TYPE man page, specifically with regard to the analyze_function clause? Basically, if you want anything different, you have to write an analysis function yourself. This is what PostGIS (www.postgis.org) does, if you want to look for specific code examples. I have read it and works great, because it says it uses the default operators = and < to build the statistics which should work great for the default operator class.I don't think I need to write my own analyze function because the default behavior works so well. I just want the ANALYZE call to use the index's opclass definitions of = and < if the index is created with a custom operator class that is not the default for the data type. ANALYZE collects stats for tables, not indexes, using the default operator class for the datatype. So even though you've clearly specified an opclass for the index, no stats will be collected using it. I don't think thats correct because, with indexes based on functions there are statistics that clearly can't be gathered just directly from the table. Analyze does look at indexes to build up the histogram statistics and correlation. See compute_index_stats in analyze.c. Alternatively, perhaps you have fallen foul of this situation? /* * Can't analyze if the opclass uses a storage type * different from the expression result type. We'd get * confused because the type shown in pg_attribute for * the index column doesn't match what we are getting * from the expression. Perhaps this can be fixed * someday, but for now, punt. */ It's in the analyze.c code, but not in the docs. Be interested in a full report of your research, once you're done. I don't think this applies because the storage type is the same its just a separate operator class being used. I think the problem may be with the "ordering_oper" and "equality_oper" only being passed the type rather then the type and the operator class that's being used for the index. Looking more it goes back into typcache.c which only caches the default operators from the default btree or hash operator classes. Changing this looks like it would require a bit of effort if it is the right path to pursue. Thanks, Rusty -- Rusty Conover InfoGears Inc. Web: http://www.infogears.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] Operator Classes and ANALYZE
On Mon, 2006-11-06 at 14:47 -0700, Rusty Conover wrote: > I just > want the ANALYZE call to use the index's opclass definitions of = and > < if the index is created with a custom operator class that is not > the default for the data type. Which is exactly what the manual specifically says it doesn't do, therefore you'll need the analyze_function. That capability was put there deliberately to help you out, in this situation. > I don't think I need to write my own analyze function That is the solution, not a workaround. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] Operator Classes and ANALYZE
On Nov 6, 2006, at 3:20 PM, Simon Riggs wrote: On Mon, 2006-11-06 at 14:47 -0700, Rusty Conover wrote: I just want the ANALYZE call to use the index's opclass definitions of = and < if the index is created with a custom operator class that is not the default for the data type. Which is exactly what the manual specifically says it doesn't do, therefore you'll need the analyze_function. That capability was put there deliberately to help you out, in this situation. Since the analyze function is part of the type not the operator class (making it type specific not operator class specific), it doesn't appear that it will be able to do what I ask since you can only have one analyze function per type and its not passed the operator context for the particular run. from analyze.h: /*-- * ANALYZE builds one of these structs for each attribute (column) that is * to be analyzed. The struct and subsidiary data are in anl_context, * so they live until the end of the ANALYZE operation. * * The type-specific typanalyze function is passed a pointer to this struct * and must return TRUE to continue analysis, FALSE to skip analysis of this * column. In the TRUE case it must set the compute_stats and minrows fields, * and can optionally set extra_data to pass additional info to compute_stats. * minrows is its request for the minimum number of sample rows to be gathered * (but note this request might not be honored, eg if there are fewer rows * than that in the table). * */ I still think this is a deficiency in the analyze function to not use the operator_class that the index uses when producing statistics for that index. Thanks, Rusty -- Rusty Conover InfoGears Inc. Web: http://www.infogears.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Operator Classes and ANALYZE
On Mon, Nov 06, 2006 at 08:53:28PM +, Simon Riggs wrote: > On Fri, 2006-11-03 at 15:16 -0700, Rusty Conover wrote: > > > It doesn't appear that ANALYZE uses the specified operator class for > > producing statistics on an index when that operator class is not the > > default for the data type. This appears to be leading to poor query > > planning. > > > For speed of indexing a few million urls I'm indexing them with a > > custom data type. The data type aptly named "urlhash" has: > > Have you read the CREATE TYPE man page, specifically with regard to the > analyze_function clause? Basically, if you want anything different, you > have to write an analysis function yourself. This is what PostGIS > (www.postgis.org) does, if you want to look for specific code examples. > > ANALYZE collects stats for tables, not indexes, using the default > operator class for the datatype. So even though you've clearly specified > an opclass for the index, no stats will be collected using it. > > Alternatively, perhaps you have fallen foul of this situation? > > /* > * Can't analyze if the opclass uses a storage type > * different from the expression result type. We'd get > * confused because the type shown in pg_attribute for > * the index column doesn't match what we are getting > * from the expression. Perhaps this can be fixed > * someday, but for now, punt. > */ > > It's in the analyze.c code, but not in the docs. Should a doc patch be in the offing here? Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] Operator Classes and ANALYZE
On Mon, 2006-11-06 at 15:54 -0700, Rusty Conover wrote: > I still think this is a deficiency in the analyze function to not use > the operator_class that the index uses when producing statistics for > that index. Agreed, but that isn't the way it works right now, AFAICS. TODO... -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
