Re: [BUGS] Beta3 much slower than Beta2
Enrico Riedel wrote: To the setup: I use the Win32 version of PGRE SQL8. The table that I am working with has about 1.1M records in it and is indexed on several columns. By searching the indexed columns the DB used to be very fast. The data retrieval used to be more or less instantaneous. In Beta 3 it takes about 4 seconds to retrieve the same amount of data. E.g. I searched for "EAG", which returns about 50 records. In B2 the retrieval time was less than 1s, in B3 it's about 3-4 seconds. This is likely not a bug in beta3 as such; what has probably happened is that the query planner is choosing a different query plan in beta3 than was chosen in beta2. Without more information, it is difficult to say exactly why a different plan is being chosen. Have you run ANALYZE recently? If so, can you provide the schemas of the relevant tables, the query that has changed in performance, and the EXPLAIN ANALYZE output for that query against beta3? -Neil ---(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: [BUGS] Beta3 much slower than Beta2
I switched "in place" from beta2 to beta3 on windows some weeks ago (selfcompiled), no notable speed difference. Did you the usual "analyze" ritual??? Are the indexes used? Did you compare the "explain" outputs? Are the indexes really present? Harald ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Problem with rule and null value
>ON UPDATE TO album WHERE new.pls_id != old.pls_id > It works until new.pls_id or old.pls_id is null. The rule is still called > (based on my test), but the "DO" query is not executed correctly. The > values in "album_edit" are not updated. To compare "NULL" to something is allways a bad idea. The behaviour in Postgres is exactly as documented and specified within the SQL-standard. BUT... that is quite different from what you would expect. To test on "NULL" values within SQL only "is null" is helpfull. I would strongly recommend to you to read the appropriate chapters about Null-Values. It seems strange at first but managable. Harald ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] select() failed in statistics collector
James, that error is well documented in the PGINSTALLER-FAQ on pgfoundry. Problem: "something" is interfering with socket-inheritance. "something" most offen is some kind of "Layered service provider" as is: Antivir software, Age Verfication Software..." Workaround now: "something" has to be uninstalled "solution" longterm 1: "something" has to be changed to respect the specification solution longterm 2: there is a quite complicated patch available for the win32-socket code. I someone with enough win32 socket programming excellence AND available time is willing to donate that time and excellence to postgresql ... that workaround might be implemented. Harald ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Question on the 8.0Beta Version
> > I have read on the installation note file that postgres server will not > > run with administrative permissions. I have read on your forum that this > > happened because i have installed the beta version: is it true that this > > happen only with the beta version? It is written by the core developers that "running postgres with admin privileges" will never be possible. (at least with the official sources) It has been discussed in detail; with pro and cons and it was a very informed decission. You can read it wihtin the PSQL-Hackers list. Harald ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] Beta3 much slower than Beta2
>I switched "in place" from beta2 to beta3 on windows some weeks ago >(selfcompiled), no notable speed difference. There may be a different issue here as well. The pginstaller version is "beta3deva1", which is *not* beta3. It is a post-beta3 snapshot from oct 20th. If something has changed there, that could be the reason. That said, I haven't noticed these symptoms myelf, so I'd check the other suggestions first. //Magnus ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] [GENERAL] Question on the 8.0Beta Version
On Fri, 2004-10-22 at 00:59, Davide Negri wrote: > Hello, > > i have installed postgres 8.0 beta3 as a program on my pc on windows > xp. I have read on the installation note file that postgres server > will not run with administrative permissions. I have read on your > forum that this happened because i have installed the beta version: is > it true that this happen only with the beta version? When will you > plan to release the production version? I think you may have misunderstood the docs. PostgreSQL doesn't run under any account that has machine admin / root privelages because that makes any small security issue in postgresql into a root level exploit, and that's a bad thing. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] [Slony1-general] Thread-safety detection on HP-UX
On 10/23/2004 10:08 PM, Tom Lane wrote: Jan Wieck <[EMAIL PROTECTED]> writes: On 10/22/2004 3:30 PM, Ed L. wrote: Clean build of pgsql 7.4.5 on HPUX B.11.23 on ia64 with --enable-thread-safety fails ... :( Unfortunately that doesn't mean that the switch is required to cause libpq to behave nicely for the Slony purposes. Can someone please test if Slony works on HP-UX even if PostgreSQL is NOT configured with --enable-thread-safety ? FWIW, CVS tip does build with --enable-thread-safety on HPUX 11.23 ... at least for me ... regards, tom lane The patch available from http://slony.info should allow that for 7.4.x as well since it was the base for switching from our clumsy template file collection to acx_pthreads. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] BUG #1292: ecpg precompile bug (valiable typedef & define )
The following bug has been logged online:
Bug reference: 1292
Logged by: shigeto aya
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.2
Operating system: Red Hat Linux Advanced Server release 2.1AS/i686
(Pensacola)
Description:ecpg precompile bug (valiable typedef & define )
Details:
The result to demand cannot be found although the following programs were
performed.
Demand :
data insert --
100
200
300
400
500
600
700
800
select --
100
200
300
400
500
600
700
800
Execution result
data insert --
100
200
300
400
500
600
700
800
select --
1
200
300
400
5
600
700
800
sample program -
#include
/**/
/* create table test_table ( retu text ); */
/**/
int main() {
#define LEN 3
exec sql begin declare section;
typedef char TYPE1[LEN+1];
typedef char TYPE2[3+1];
struct {
TYPE1 val1;/* NG */
TYPE2 val2;/* OK */
char val3[LEN+1]; /* OK */
char val4[3+1]; /* OK */
} k ;
TYPE1 val5; /* NG */
TYPE2 val6; /* OK */
char val7[3+1];/* OK */
char val8[LEN+1]; /* OK */
char fetch_val[4];
exec sql end declare section;
exec sql connect to aya;
exec sql begin work;
printf("data insert -- \n");
strcpy ( k.val1, "100"); printf("%s\n", k.val1);
strcpy ( k.val2, "200"); printf("%s\n", k.val2);
strcpy ( k.val3, "300"); printf("%s\n", k.val3);
strcpy ( k.val4, "400"); printf("%s\n", k.val4);
strcpy ( val5, "500"); printf("%s\n", val5);
strcpy ( val6, "600"); printf("%s\n", val6);
strcpy ( val7, "700"); printf("%s\n", val7);
strcpy ( val8, "800"); printf("%s\n", val8);
exec sql delete from test_table;
exec sql insert into test_table values ( :k.val1 ) ; /* bug ? */
exec sql insert into test_table values ( :k.val2 ) ; /* ok */
exec sql insert into test_table values ( :k.val3 ) ; /* ok */
exec sql insert into test_table values ( :k.val4 ) ; /* ok */
exec sql insert into test_table values ( :val5 ) ; /* bug ? */
exec sql insert into test_table values ( :val6 ) ; /* ok */
exec sql insert into test_table values ( :val7 ) ; /* ok */
exec sql insert into test_table values ( :val8 ) ; /* ok */
exec sql declare acur cursor for select retu1 from test_table ;
exec sql open acur;
printf("select -- \n");
while(1) {
memset ( fetch_val, '\0', sizeof ( fetch_val ) );
exec sql fetch acur into :fetch_val ;
if (sqlca.sqlcode != 0 ){
break;
}
printf ("%s\n",fetch_val);
}
exec sql commit work;
exec sql disconnect;
exit( 0 );
}
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [BUGS] BUG #1290: Default value and ALTER...TYPE
Tom Lane wrote: Possibly we should make ALTER COLUMN strip any implicit coercions that appear at the top level of the default expression before it adds on the implicit coercion to the new column datatype. That seems like a kludge. When processing a column default expression, we: (1) Accept the default's raw parsetree from the parser (2) Convert it to a cooked parsetree via transformExpr() (3) Add a coercion to the table's column type Can't we save the cooked parsetree that we produced in #2? That would mean we can just reuse the cooked parsetree (w/o the coercion) and add a coercion to the correct column type @ ALTER TABLE time. -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [BUGS] BUG #1290: Default value and ALTER...TYPE
On Sun, 24 Oct 2004, Neil Conway wrote: > (1) Accept the default's raw parsetree from the parser > (2) Convert it to a cooked parsetree via transformExpr() > (3) Add a coercion to the table's column type > > Can't we save the cooked parsetree that we produced in #2? One could even save the string as it was before parsning if one wants to (could make it easier to edit in a graphical client like pgadmin3). -- /Dennis Björklund ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [BUGS] BUG #1290: Default value and ALTER...TYPE
Neil Conway <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Possibly we should make ALTER COLUMN strip any implicit coercions that >> appear at the top level of the default expression before it adds on the >> implicit coercion to the new column datatype. > That seems like a kludge. When processing a column default expression, we: > (1) Accept the default's raw parsetree from the parser > (2) Convert it to a cooked parsetree via transformExpr() > (3) Add a coercion to the table's column type > Can't we save the cooked parsetree that we produced in #2? Not without an initdb (to have another column to put it in). And it would produce exactly the same result anyway, because the only way there could be implicit coercion steps at the top of the expression is because step 3 put them there. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [BUGS] BUG #1290: Default value and ALTER...TYPE
On Sun, 24 Oct 2004, Tom Lane wrote: > > (1) Accept the default's raw parsetree from the parser > > (2) Convert it to a cooked parsetree via transformExpr() > > (3) Add a coercion to the table's column type > > > Can't we save the cooked parsetree that we produced in #2? > > Not without an initdb (to have another column to put it in). And it > would produce exactly the same result anyway, because the only way there > could be implicit coercion steps at the top of the expression is because > step 3 put them there. Yes, and he suggested to not perform step 3. Instead one need to do that when the default value is used. -- /Dennis Björklund ---(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] [BUGS] BUG #1290: Default value and ALTER...TYPE
On Mon, 2004-10-25 at 00:30, Tom Lane wrote: > Not without an initdb (to have another column to put it in). We're already requiring an initdb for beta4; if this is the right way to fix this (and I'm not insisting that it is), then ISTM we can just push back beta4 a few days. > And it > would produce exactly the same result anyway, because the only way there > could be implicit coercion steps at the top of the expression is because > step 3 put them there. Per your earlier comment: "I am not sure that this is a good idea, however; it seems like it might alter the semantics in unexpected ways. (The default expression could potentially come through differently than an actually stored value of the column would do.)" So you can't have it both ways :) I think it's somewhat fragile to remove the coercion by hand at ALTER TABLE time, but as you say, I can't think of a reason why it wouldn't work. -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [BUGS] BUG #1290: Default value and ALTER...TYPE
Neil Conway <[EMAIL PROTECTED]> writes: > On Mon, 2004-10-25 at 00:30, Tom Lane wrote: >> And it >> would produce exactly the same result anyway, because the only way there >> could be implicit coercion steps at the top of the expression is because >> step 3 put them there. > Per your earlier comment: "I am not sure that this is a good idea, > however; it seems like it might alter the semantics in > unexpected ways. (The default expression could potentially come through > differently than an actually stored value of the column would do.)" > So you can't have it both ways :) Sure I can. The method you propose will produce exactly the same results as what's in there. I am still a bit concerned about nonintuitive results in some cases, but changing it like this wouldn't fix that; it's just a different way of getting to the same place. The bottom line here is what will produce the least surprise in the most cases. The case that actually convinced me to do it was thinking about serial columns. As it is now, "ALTER COLUMN TYPE bigint" will successfully convert a serial to a bigserial; before, it wouldn't, because the result of nextval() would still get squeezed down to int4. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] BUG #1293: INSERT INTO test (f1.f2) VALUES (1,2) - wrong diagnostic
The following bug has been logged online: Bug reference: 1293 Logged by: Alexander Kirpa Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Beta Operating system: FreeBSD Description:INSERT INTO test (f1.f2) VALUES (1,2) - wrong diagnostic Details: create table test(f1 int4,f2 int4); insert into test (f1.f2) values (1,2); ERROR: cannot assign to a column of type integer because it is not a composite type select f1.f2 from test; relation "f1" does not exist Wrong diagnostic for INSERT ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] BUG #1293: INSERT INTO test (f1.f2) VALUES (1,2) - wrong diagnostic
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > create table test(f1 int4,f2 int4); > insert into test (f1.f2) values (1,2); > ERROR: cannot assign to a column of type integer because it is not a > composite type This diagnostic is not wrong. It might be a tad unhelpful, but I don't think it's within the province of the parser to intuit that you meant to type a comma instead of a period. 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
