[BUGS] BUG #4312: Installation fails
The following bug has been logged online: Bug reference: 4312 Logged by: Bhaskar Sirohi Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.3 Operating system: Windows 2003 Server Description:Installation fails Details: I tried to install Postresql 8.3.3 on the server. Install autocreates user, but when it comes to start the service, I am told that the users do not have enough rights. Also see the installation log: Property(C): OutOfDiskSpace = 0 Property(C): OutOfNoRbDiskSpace = 0 Property(C): PrimaryVolumeSpaceAvailable = 0 Property(C): PrimaryVolumeSpaceRequired = 0 Property(C): PrimaryVolumeSpaceRemaining = 0 Property(C): INSTALLLEVEL = 1 === Logging stopped: 03.07.2008 14:30:21 === MSI (c) (DC:E8) [14:30:21:943]: Note: 1: 1708 MSI (c) (DC:E8) [14:30:21:943]: Note: 1: 2205 2: 3: Error MSI (c) (DC:E8) [14:30:21:943]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1708 MSI (c) (DC:E8) [14:30:21:959]: Note: 1: 2205 2: 3: Error MSI (c) (DC:E8) [14:30:21:959]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 MSI (c) (DC:E8) [14:30:21:959]: Product: PostgreSQL 8.3 -- Installation failed. MSI (c) (DC:E8) [14:30:21:975]: Grabbed execution mutex. MSI (c) (DC:E8) [14:30:21:975]: Cleaning up uninstalled install packages, if any exist MSI (c) (DC:E8) [14:30:21:975]: MainEngineThread is returning 1603 === Verbose logging stopped: 03.07.2008 14:30:21 === -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4312: Installation fails
On Thu, Jul 17, 2008 at 8:05 AM, Bhaskar Sirohi <[EMAIL PROTECTED]> wrote: > > The following bug has been logged online: > > Bug reference: 4312 > Logged by: Bhaskar Sirohi > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3.3 > Operating system: Windows 2003 Server > Description:Installation fails > Details: > > I tried to install Postresql 8.3.3 on the server. Install autocreates user, > but when it comes to start the > service, I am told that the users do not have enough rights. Anything in the event log, or the pg_log directory under the data directory? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] MAX関数に関する報告
PostgreSQL7.4 および PostgreSQL8.1 の間でMAX関数による出力結果の違いがありましたので報告いたします。 --テスト用テーブルの作成 create table b ( item1 char(10), item2 varchar(10) ); --データの追加 insert into b ( item1, item2 ) values ( '1234', '5678' ); insert into b ( item1, item2 ) values ( 'ABCD', 'EFGH' ); --データの抽出 select max(item1) as item1 , max(item2) as item2 from b ; □7.4での出力結果 item1 item2 ABCDEFGH □8.1での出力結果 item1 item2 - ABCDEFGH となります。 item1がchar型のとき、パディングされている後方スペースがPostgreSQL8.1では取り除かれていませんでした。 仕様変更点および、過去のバグ報告にも記載がな買った内容のため、報告させていただきます。 よろしくお願いいたします。 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4307: INSERT fails with primary key contraint
I use NHibernate 1.2.1.4 and Npgsql 0.7.1 database driver for data
access layer. From your comments it looks like these components are
responsible for INSERT statement creation (mostly NHibernate).
I think you can close this bug and I will search for solutions in
NHibernate community.
Gregory Stark wrote:
"Oskars Ozols" <[EMAIL PROTECTED]> writes:
id bigint NOT NULL DEFAULT nextval(('public.event_log_id_seq'::text)::regclass),
2008-07-15 12:32:03 EEST STATEMENT: INSERT INTO public.event_log
(date_time, ip_address, action_type, severity, parameters, web_address,
server, user_id, id) VALUES ('2008-07-15 12:28:50.00',
'123.123.123.123', 'WebServices.SomeService:LogError', 7, 'error text',
'http://123.123.123.123/WebServices/SomeService.asmx', '4', 75, 156112)
There's something strange here. Your SQL statement includes the id as a
literal constant 156112. This isn't the normal way to write this query. This
is defeating the point of the DEFAULT you see in the table definition.
Postgres guarantees that the nextval() function will only return each value
once. But it's not clear from this log how your application is generating the
156112 value which it is explicitly putting in the query. If it's getting it
by calling nextval() then it's somehow using it twice.
It's also possible someone has written code to pick primary key values by
calling "select max(id)+1". That is guaranteed to have race conditions like
this.
The safest thing to do is to just leave out the id column from your INSERT
statement. Just let the DEFAULT expression generate a value for you. Then you
can use curval('event_log_id_seq') to find out what value it generated.
--
Oskars Ozols
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] MAX関数に関する報告
"y_takesue" <[EMAIL PROTECTED]> wrote: > PostgreSQL7.4 および PostgreSQL8.1 の間でMAX関数による出力結果の違いがありましたので報告いたします。 > item1がchar型のとき、パディングされている後方スペースがPostgreSQL8.1では取り除かれていませんでした。 リリースノートを見ても、どこで変更されたか特定できませんでしたが、 max() が text 型のみだけではなく、char 型のサポートが追加されたことが 影響しているようです。max() 後の値を必要な型に明示的にキャストするのが 安全だと思われます。 BTW, max() returns bpchar type for char(10) and text for varchar(10) in HEAD. The type modifiers are lost. Is it a limitation? postgres=# \d b Table "public.b" Column | Type | Modifiers +---+--- item1 | character(10) | item2 | character varying(10) | postgres=# select max(item1) as item1 , max(item2) as item2 into result from b; [in 7.4] postgres=# \d result Table "public.result" Column | Type | Modifiers +--+--- item1 | text | <- not a char(10) item2 | text | <- not a varchar(10) [in HEAD] postgres=# \d result Table "public.result" Column | Type | Modifiers ++--- item1 | bpchar |<- type modifier 10 is lost item2 | text |<- type modifier 10 is lost postgres=# EXPLAIN VERBOSE select max(item1) as item1 , max(item2) as item2 into result from b; QUERY PLAN --- Aggregate (cost=20.81..20.81 rows=1 width=82) Output: max(item1), max((item2)::text) -> Seq Scan on b (cost=0.00..17.20 rows=720 width=82) Output: item1, item2 (4 rows) Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4313: Strange optimizer behaviour
The following bug has been logged online:
Bug reference: 4313
Logged by: Daniel Podlejski
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1, 8.3.3
Operating system: Linux
Description:Strange optimizer behaviour
Details:
cvalley_dev=# \d messages
Table "public.messages"
Column |Type | Modifiers
+-+-
--
id | integer | not null default
nextval('messages_id_seq'::regclass)
sender_id | integer | not null
rcptto_id | integer | not null
subject| text|
body | text|
read | boolean | not null default false
deleted| boolean | not null default false
created_at | timestamp without time zone |
updated_at | timestamp without time zone |
Indexes:
"messages_pkey" PRIMARY KEY, btree (id)
cvalley_dev=# EXPLAIN SELECT * FROM messages WHERE (messages."id" = 11);
QUERY PLAN
---
Index Scan using messages_pkey on messages (cost=0.00..8.35 rows=1
width=51)
Index Cond: (id = 11)
(2 rows)
cvalley_dev=# EXPLAIN SELECT * FROM messages WHERE (messages."id" =
11);
QUERY PLAN
-
Seq Scan on messages (cost=0.00..23400.56 rows=4588 width=51)
Filter: ((id)::numeric =
11::numeric)
(2 rows)
I think there is no sense to cast too big value to numeric when field type
is integer.
On really big table this "bug" cause unnecessary io load.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4313: Strange optimizer behaviour
"Daniel Podlejski" <[EMAIL PROTECTED]> writes: > I think there is no sense to cast too big value to numeric when field type > is integer. > On really big table this "bug" cause unnecessary io load. Well, for example, the same logic doesn't hold for < where all the records would satisfy the inequality but only numeric.< will be able to handle the argument. I think you could get the behaviour you're looking for by using an untyped quoted constant like '11' instead of using an integer constant. The fact that these two cases behave differently is a bit confusing too. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
