[BUGS] Problem in Postgresql installation
Hi I have installed a 7.1.3 postgresql version on my linux server. (RedHat 7.2) When I type "createuser "it asks me : Shall the new user allowed to create databases (y/n)? Shall the new user allowed to create more new user (y/n)? I answer yes to the both questions and then a bug report said : " psql : connetDbstart() -- connect() failed - no such file or directory Is the postmaster running locally and accepting connections onUnix socket :'/tmp/.s.PSQL.5432' createuser : creation of user 'xxx' failed. I already had answers to this but I am a newbie in linux, so i didn't understand what i have to do exactly to resolve this problem. Someone wrote me : 1. Did you initialized your database with initdb ? 2. Have you started Postgres with postmaster -i or pg_ctl start ? 3. Have you modified parameters in $PGDATA/postgresql.conf file ? Follow your answers, you have solved your problem 1.When i type initdb it said me that it's not possible to create specific directories (pgsql and data) 2. Howam I supposed to use the postmaster or pg_ctl ?? 3. The installation is not complete so i haven't a postgresql.conf file Thanks for your help. Mr Paquin
Re: [BUGS] What's the difference?
Victor Wagner [EMAIL PROTECTED] writes: As far as I understand, following three queries are exactly equivalent: Same results, but the second two constrain the planner's choice of join order. See http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/explicit-joins.html Whether this is a feature or a bug depends on context... regards, tom lane I can agree that this is feature if one uses natural or inner joins. But if query semantic needs outer joins there is no way to tell the planner that it is free to choose order of joining. Only thing left is to join with result of subquery, which makes entire query much less readable. I'd think that simpliest way of writing query should result in most freedom for optimizer to choose an execution plan. It is so for inner joins, but not for outer ones. -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] What's the difference?
Victor Wagner [EMAIL PROTECTED] writes: Same results, but the second two constrain the planner's choice of join order. See http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/explicit-joins.html Whether this is a feature or a bug depends on context... regards, tom lane I can agree that this is feature if one uses natural or inner joins. But if query semantic needs outer joins there is no way to tell the planner that it is free to choose order of joining. But it is *not* free to alter the join order of outer joins; if it does, that will change the result. See the discussion on the above-linked page. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] Bug #630: date/time storage problem: timestamp parsed incorrectly...
Sean Chittenden ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
date/time storage problem: timestamp parsed incorrectly...
Long Description
It looks like a bad parser or defaults for time values. The example code below
explains the problem best. I'm not sure why, or where... but it took me about a day
to track down (PostgreSQL is never wrong!). If I include a timezone, things seem to
work. For some reason, only dates from yesterday and today break things... I think
it's because -7 is the same as my timezone, PST (now -7).
Sample Code
CREATE TABLE timestamp_test (
utc_timestamp TIMESTAMP NOT NULL
);
INSERT INTO timestamp_tmp VALUES ('2002-4-7 2:0:0.0');
SELECT * from timestamp_tmp;
utc_date
2036-06-02 22:55:24-07
(1 row)
INSERT INTO timestamp_tmp VALUES ('2002-4-7 -8 2:0:0.0');
SELECT * from timestamp_tmp;
utc_date
2036-06-02 22:55:24-07
2002-04-07 03:00:00-07
(2 rows)
No file was uploaded with this report
---(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] Bug #630: date/time storage problem: timestamp parsed incorrectly...
date/time storage problem: timestamp parsed incorrectly... It looks like a bad parser or defaults for time values. The example code below explains the problem best. I'm not sure why, or where... but it took me about a day to track down (PostgreSQL is never wrong!). If I include a timezone, things seem to work. For some reason, only dates from yesterday and today break things... I think it's because -7 is the same as my timezone, PST (now -7). Well, as long as you realize that PostgreSQL is always right you are on track ;) I'm guessing that you have a damaged timezone database on your system. What time zone does your system think it is in? What system are you running on? I'm not seeing a problem on my Linux box running 7.2 (well, except for the jump at the time zone boundary): lockhart=# select timestamp '2002-4-7 2:0:0.0'; timestamptz 2002-04-07 01:00:00-08 (1 row) But that is not the 2036 result you are seeing, so I can only speculate on your specific problem... ACK! Hmm... fresh build of FreeBSD: $ uname -a FreeBSD ninja1.internal 4.5-STABLE FreeBSD 4.5-STABLE #0: Fri Apr 5 18:08:12 PST 2002 [EMAIL PROTECTED]:/opt/obj/opt/src/sys/NINJA i386 $ psql # SELECT timestamp '2002-4-7 2:0:0.0'; timestamptz 2036-06-02 22:57:08-07 (1 row) # SELECT version(); version PostgreSQL 7.2 on i386--freebsd4.5, compiled by GCC 2.95.3 (1 row) This isn't happy making. What OS are you running? Seems like a lower level problem. Do you know if it's a system call making the formatting call? -sc -- Sean Chittenden ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Bug #630: date/time storage problem: timestamp parsed
date/time storage problem: timestamp parsed incorrectly... It looks like a bad parser or defaults for time values. The example code below explains the problem best. I'm not sure why, or where... but it took me about a day to track down (PostgreSQL is never wrong!). If I include a timezone, things seem to work. For some reason, only dates from yesterday and today break things... I think it's because -7 is the same as my timezone, PST (now -7). Well, as long as you realize that PostgreSQL is always right you are on track ;) I'm guessing that you have a damaged timezone database on your system. What time zone does your system think it is in? What system are you running on? I'm not seeing a problem on my Linux box running 7.2 (well, except for the jump at the time zone boundary): lockhart=# select timestamp '2002-4-7 2:0:0.0'; timestamptz 2002-04-07 01:00:00-08 (1 row) But that is not the 2036 result you are seeing, so I can only speculate on your specific problem... - Thomas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Bug #630: date/time storage problem: timestamp parsed
$ uname -a FreeBSD ninja1.internal 4.5-STABLE FreeBSD 4.5-STABLE #0: Fri Apr 5 18:08:12 PST 2002 [EMAIL PROTECTED]:/opt/obj/opt/src/sys/NINJA i386 $ psql # SELECT timestamp '2002-4-7 2:0:0.0'; timestamptz 2036-06-02 22:57:08-07 # SELECT version(); version PostgreSQL 7.2 on i386--freebsd4.5, compiled by GCC 2.95.3 This isn't happy making. What OS are you running? Seems like a lower level problem. Do you know if it's a system call making the formatting call? PostgreSQL uses system calls to get the current time zone if it is not specified in the input string. I'm running a fairly new Linux (Mandrake distro), which has the zinc package as part of glibc-2.2.4 Do you have another way to verify your time zone setup? Do you have the zdump command to look at your time zone info? If you want to step through your PostgreSQL code, I could give you some suggestions on what to look for: 1) run the backend using gdb postgres 2) before telling gdb to run, set a breakpoint on DecodeDateTime and DetermineLocalTimeZone. Use b DecodeDateTime. 3) run the program. Use run dbname where dbname might be your user name. 4) at the prompt, type in the above query. 5) at first breakpoint, continue by typing c. 6) at the DetermineLocalTimeZone breakpoint, start stepping through code with s. Check values as you go along. hth - Thomas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
