Re: [BUGS] Installation fails for postgresql-8.0.0-beta4 on Windo
Hi, A further clue that can help to resolve this bug: I tried to install it on Windows 2000 & it works fine. So I think the issue might be only for Windows XP Professional systems. Regards, Mehul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mehul Doshi-A20614 Sent: Thursday, November 25, 2004 2:31 PM To: [EMAIL PROTECTED] Subject: [BUGS] Installation fails for postgresql-8.0.0-beta4 on WindowsXP SP1 Hi, I am trying to install the 8.0 beta4 version for Windows onto my system and facing an error which I can't fix. System: Windows XP, Sevice Pack 1 I am an admin on my system, but a regular user on a domain. I have created a non-admin user named "postgres" which is a member of the "Users" group (Restricted Users). I have run the entire installation in exactly the same way as is given http://pginstaller.projects.postgresql.org/ However, this is the error message that I get. Error Pop-up message: "Failed to run initdb: 1! Please see the logfile in "C:\Program Files\PostgreSQL\8.0.0-beta4\tmp\initdb.log" Note! You must read/copy this logifle before you click OK, or it will be automatically removed." Please find the log (initdb.log) below ---The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale C. fixing permissions on existing directory C:/Program Files/PostgreSQL/8.0.0-beta4/data ... ok creating directory C:/Program Files/PostgreSQL/8.0.0-beta4/data/global ... ok creating directory C:/Program Files/PostgreSQL/8.0.0-beta4/data/pg_xlog ... ok creating directory C:/Program Files/PostgreSQL/8.0.0-beta4/data/pg_xlog/archive_status ... ok creating directory C:/Program Files/PostgreSQL/8.0.0-beta4/data/pg_clog ... ok creating directory C:/Program Files/PostgreSQL/8.0.0-beta4/data/pg_subtrans ... ok creating directory C:/Program Files/PostgreSQL/8.0.0-beta4/data/base ... ok creating directory C:/Program Files/PostgreSQL/8.0.0-beta4/data/base/1 ... ok creating directory C:/Program Files/PostgreSQL/8.0.0-beta4/data/pg_tblspc ... ok selecting default max_connections ... 10 selecting default shared_buffers ... 50 creating configuration files ... ok creating template1 database in C:/Program Files/PostgreSQL/8.0.0-beta4/data/base/1 ... Execution of PostgreSQL by a user with admin! istrative permissions is not permitted. The server must be started under an unprivileged user ID to prevent possible system security compromises. See the documentation for more information on how to properly start the server. child process was terminated by signal 1 initdb: failed initdb: removing contents of data directory "C:/Program Files/PostgreSQL/8.0.0-beta4/data" --- It somehow recognizes the account as an admin, when it is definitely not. Just to check, I even tried with the admin account itself and it kicked me off right in Step 4 of the procedure. So if it goes past Step 4 it already recognizes that it is not admin account. I think this issue has been raised before http://pgfoundry.org/tracker/index.php?func=detail&aid=188&group_id=107&atid=126 Please let me know if there is something that needs to be fixed by me before this installation goes through successfully. Regards, Mehul ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS] BUG #1331: after update: vacuum blocks parallel to select
The following bug has been logged online:
Bug reference: 1331
Logged by: Michael Enke
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.5
Operating system: Linux SuSE 9.1 Kernel 2.6/RedHat 9 Kernel 2.4
Description:after update: vacuum blocks parallel to select
Details:
Hi group,
I found that vacuum blocks until a select cursor is closed but only if the
table was updated before.
After select/TA finished, vacuum goes through.
A second vacuum during parallel select doesn't block
until the next update is done.
Example code: create table, insert and update:
===vac_blk.sql start=
drop table vac_blk;
create table vac_blk (
a int2
);
insert into vac_blk values (1);
update vac_blk set a=1 where a=1;
\echo now call vac_blk binary;
\echo if running, call vacuum vac_blk: will hang
==vac_blk.sql stop
Example code: Do the select inside a TA:
==vac_blk.pgc start===
exec sql include sqlca;
int main(int argc, char **argv) {
exec sql begin declare section;
int a;
char sqlstring[] = "select a from vac_blk";
exec sql end declare section;
exec sql connect to [EMAIL PROTECTED]:5432
user myuser identified by mypassword;
exec sql PREPARE select_vac_blk FROM :sqlstring;
exec sql DECLARE select_cur_vac_blk CURSOR FOR select_vac_blk;
exec sql OPEN select_cur_vac_blk;
exec sql FETCH select_cur_vac_blk INTO :a;
printf("have read a=%i, will now sleep 60s, go vacuum now!\n", a);
sleep(60);
exec sql disconnect all;
return 0;
}
==vac_blk.pgc stop
it was compiled with
vac_blk: vac_blk.pgc
ecpg vac_blk.pgc -I/usr/include/pgsql
gcc -o vac_blk vac_blk.c -I/usr/include/pgsql -lecpg
If you call "vacuum vac_blk;" in psql after
creation, insertion and update to vac_blk table
and running vac_blk binary,
it hangs until the vac_blk program exits.
Than the vacuum finishes afterwards.
To reproduce this, you must first update the vac_blk
table. If no update, the select doesn't block the
vacuum.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] BUG #1332: wrong results from age function
The following bug has been logged online:
Bug reference: 1332
Logged by: Robert Grabowski
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.6
Operating system: Linux
Description:wrong results from age function
Details:
select age('2004-02-01'::date, '2004-01-01'::date);
age
---
1 mon
(1 row)
select age('2004-03-01'::date, '2004-02-01'::date);
age
-
29 days
(1 row)
I think, it should be "1 mon".
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [BUGS] BUG #1331: after update: vacuum blocks parallel to select
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > Description:after update: vacuum blocks parallel to select This isn't a bug, it's simply vacuum waiting until it can acquire a page-level lock. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] BUG #1331: after update: vacuum blocks parallel to select
"Enke, Michael" <[EMAIL PROTECTED]> writes: > But the description says: vacuum can run parallel to selects. > This is than not true. Sure it can; but that doesn't mean there is no interlocking at all. The issue you have is not so much that the select is running as that it is *not* running, ie, it's stopped on a particular page. As soon as it moves off the modified page, the vacuum will be able to make progress. 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: [BUGS] BUG #1329: Bug in IF-ELSEIF-ELSE construct
Neil Conway <[EMAIL PROTECTED]> writes: > (2) The syntax error message is wrong (we print a character offset and > query context that is relative to the CREATE FUNCTION statement, not the > individual SQL statement we're executing). I fooled around a bit with > defining a custom ereport() callback to print the right line number and > query context, but I couldn't get it right. Do you have any guidance on > the proper way to do this. Hmm ... I was about to say the SQL function validator already does this (see sql_function_parse_error_callback in pg_proc.c), but it has the advantage that there's a one-to-one correspondence between the string it sends to the main parser and a substring of the original function text. In plpgsql that's not true because of (a) substitution of parameter symbols for names and (b) the liberties that the plpgsql lexer takes with whitespace and eliding comments. You might be best off just to strive for output like this: ERROR: syntax error at or near... QUERY: select ... CONTEXT: compile of plpgsql function "frob" at SQL statement line 12 which ought to be relatively easy to get. BTW, don't forget to check SQL expressions (eg, the condition of an IF) as well as SQL statements. In the case of EXECUTE, you can check the expression that gives rise to the text string. >> The error would be more useful if reported immediately >> after the putative SQL statement is parsed. Not sure if that's >> hard or not. (The same remark applies to dead code checking, now >> that I think about it.) > In the case of dead code checking, I don't think it matters. My thought was that a dead-code error could well indicate a problem along the lines of a missing begin or end, and that flagging the dead-code error would probably provide a much closer pointer to the true problem than barfing at the end of the input when we realize we have unmatched begin/end structure. (Especially since the barf will likely take the form of a nonspecific "syntax error" message. Anytime you can do better than that, you're ahead.) Similarly, checking expressions immediately will help report mismatched-parenthesis problems in a more useful way than we do now. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] PLTCL
Hello I'm trying to create a new language in my database (pg 8 beta5 - Windows Xp) and the error message show me. C:\Arquivos de programas\PostgreSQL\8.0.0-beta5\bin>createlang.exe pltcl -d supremus -h localhost -U administradorPassword:createlang: language installation failed: ERROR: could not load library "C:/Arquivos de programas/PostgreSQL/8.0.0-beta5/lib/pltcl.dll": error What the problem ? The pg8 for windows beta5 don't have support to this language type ? Tks staing Luciano Almeida SC - BRAZIL
Re: [BUGS] BUG #1331: after update: vacuum blocks parallel to select
But the description says: vacuum can run parallel to selects. This is than not true. Regards, Michael Tom Lane schrieb: "PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: Description:after update: vacuum blocks parallel to select This isn't a bug, it's simply vacuum waiting until it can acquire a page-level lock. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] Ambiguous behaviour of age(timestamp)
Hello, As the documentation describes the AGE() function - http://developer.postgresql.org/docs/postgres/functions-datetime.html#FUNCTIONS-DATETIME-TABLE , there are two signatures: - AGE(timestamp); - AGE(timestamp, timestamp). I think the documentation is misleading, because AGE(timestamp) is actually converted to AGE(current_date, timestamp), and not to AGE(now(), timestamp). So for example: test=> select age(now()); age -- -17:23:32.589739 (1 row) I'm actually receiving the *age* of now() compared to the start of the day 0:00. Thus: test=> select age(now() - interval '1 day'); age - 06:34:45.945311 (1 row) returns not an age of 1 day but the age of yesterday's timestamp compared to 0:00 of today. However: test=> select age(now(), now() - interval '1 day'); age --- 1 day (1 row) Which is correct. As I initially understood the docs, the second form of age(timestamp, timestamp) is the same as the first one - age(timestamp), with the exception that the counting is not started from *today* but from custom timestamp instead; and because the arguments are of type 'timestamp' and not 'date' I supposed that now() is applied as a default first argument. I am not sure what is the right behaviour of this function (I think it's not correct now), but at least there have to be some explanations in the documentation. Regards, Kouber Saparev ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] PLTCL
"Luciano - UNILOG SA" <[EMAIL PROTECTED]> writes:
> createlang: language installation failed: ERROR: could not load library =
> "C:/Arquivos de programas/PostgreSQL/8.0.0-beta5/lib/pltcl.dll": error
> What the problem ?
Good question. The unhelpful error message can evidently be blamed on
this routine in src/backend/port/dynloader/win32.c:
char *
dlerror(void)
{
return "error";
}
Would someone work on providing a non-stub version of that?
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] 8.0 Beta-5 Linux PSQL Endless loop
I have two identical Dell Dimension 8400's running the exact same versions of Gentoo Linux, running the same build for PG 8.0 Beta 5. One box works fine. The other, no matter what I do, eventually runs into what appears to be an infinite loop trying to connect to the postmaster. It virtually brings the whole system down, and looks like it is allocating a lot of memory as well. I have tried to run strace on the psql process, and all I can see before the machine becomes unrepsonsive is read() over and over. Ultimtelty, the psql process ends with "LOG: unexpected EOF on client connection" I've completely cleaned out all old PG installations, binaries, and data. I've never seen this before w/ PG. My system is as follows: gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) Linux 2.6.6 #21 SMP Mon Nov 1 14:08:10 CST 2004 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux I can provide shell access to this machine if it helps. -- Mike ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] Serial id not incrementing when manual ids are used, User Error? Bug?
Hello Everyone, My name is Matt, this is my first post to the list. I've been using post for a while and love it. I haven't had any issues with it and i have found it to be a great and very flexible system. That said... I looked through the archives a bit but could not find what i was looking for so here goes: It seems that when i manually insert an id into a serial id column the sequence doesn't get updated so that when i: CREATE TABLE table1 ( table1_id SERIAL, name VARCHAR( 255 ), PRIMARY KEY( table1_id ) ); // Manually set id during a migration process INSERT INTO table1( table1_id, name ) VALUES( 1, 'test' ); the id 1 has now been used, er, should be used. Then when i: // Let post use seq to set id when inserting brand new record INSERT INTO table1( name ) VALUE( 'Matt' ); post tries to use the id 1 "again" and the insert fails. Shouldn't post know that i already used 1 and use the next val in the sequence, in this case post should really say, hey 1 is used i will set the id to 2. I should then end up with 2 records table1_id | name 1 | test 2 | Matt So does post not update a SERIAL column sequence when id's are manually entered? Would I have to manually do a nextval on the seq when manually setting id's? Should't post know that i used an id number and use the next availible number, something like ( (the largest id number in the key) + increment_val )? I can elaborate more if needed. Thanks in advance!!! Matt ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] 8.0 Beta-5 Linux PSQL Endless loop -- Followup
This problem seems to be related to the .psql_history file. If I delete the file, the problem does not occur and psql starts up fine. However, when I run psql again (after the previous session had generated a .psql_history file), the problem occurs. strace shows something like read(4, "", 131072) = 0 . . (hundreds) . . brk(0) = 0x39f8d000 brk(0x39fae000) = 0x39fae000 read(4, "", 131072) = 0 . . (hundreds) . . So it seems to be something related to reading the .psql_history file. -- Mike ---(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] 8.0 Beta-5 Linux PSQL Endless loop -- Followup
On Mon, 2004-11-29 at 17:10 -0600, Michael Owens wrote: > This problem seems to be related to the .psql_history file. If I > delete the file, the problem does not occur and psql starts up fine. > However, when I run psql again (after the previous session had > generated a .psql_history file), the problem occurs. Reading from .psql_history is implemented via libreadline, so I suspect something is awry with your readline install. What version of readline are you using? -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] 8.0 Beta-5 Linux PSQL Endless loop -- Followup
Michael Owens <[EMAIL PROTECTED]> writes: > ... So it seems to be something related to reading the .psql_history file. psql itself doesn't even know that .psql_history exists; that file is only touched by the readline library (or possibly libedit, if you are using that instead of readline; not likely since you are on Linux but I mention it for completeness). In short: seems like there's something wrong with your libreadline installation. What version of that are you using? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] 8.0 Beta-5 Linux PSQL Endless loop -- Followup
Michael Owens <[EMAIL PROTECTED]> writes: > Yeah, that was it. I started to look into that after you last email > and discovered that I had libedit installed. I was tinkering around > with it a few weeks back. I just unmerged libedit and got it off my > system. As soon as I tried to shutdown PG, pg_ctl complained about the > missing libedit library. I rebuilt PG, which this time did not use > libedit, rather readline, and it worked fine. Interesting. Either your libedit installation was broken (not entirely unlikely on Gentoo, which is way too bleeding-edge for my tastes ;-)) or there is some bit-rot in our support for libedit. The latter seems possible since AFAIK the vast majority of PG users use readline. Can any libedit users confirm it still works with PG current?? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] Serial id not incrementing when manual ids are used, User Error? Bug?
On Mon, Nov 29, 2004 at 03:47:27PM -0500, [EMAIL PROTECTED] wrote: > So does post not update a SERIAL column sequence when id's are > manually entered? Would I have to manually do a nextval on the seq > when manually setting id's? Should't post know that i used an id > number and use the next availible number, something like ( (the > largest id number in the key) + increment_val )? SERIAL is just a convenient way of creating an INTEGER column with a default value. If you provide a value for that column then the default isn't used, so the INSERT never calls nextval() to increment the sequence. If you need to set some of the SERIAL column's values explicitly, e.g., when importing data, then you can use ALTER SEQUENCE or setval() when you're finished to change the sequence's value. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(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
