Re: [BUGS] Provide a way to not ask for a password in psql
Martin Pitt wrote: > For example, "psql -l" is a convenient > method to check whether the postmaster is running at all, > finished with startup and ready for connections. > Why not just "pg_ctl status"? -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] plpythonu execute - create function bug?
"blay bloo" <[EMAIL PROTECTED]> writes: > Unfortunately this crashes postmaster v8.0.3. > ... > /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x165c)[0x61d5f6c] I think the short answer is that PG 8.0.x doesn't support python 2.5, period. Why do you feel that you must use a hoary PG version but it's OK to have a bleeding-edge Python in there? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #3664: CANNOT LOAD FROM FILE
The following bug has been logged online: Bug reference: 3664 Logged by: Maciej Szarlinski Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.5 Operating system: Windows XP SP 2 Description:CANNOT LOAD FROM FILE Details: Problem appears when I try to load a code from a file (with appropiate extension .sql). In terminal, I write '\i C:\...\file.sql' and then I've got message 'C:: Permission denied'. I would be grateful if you could give me some solution to this problem. ---(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] BUG #3663: Installer: Encoding(Server) Select list have not UTF-8 encoding.
Kevin.Lee wrote: > The following bug has been logged online: > > Bug reference: 3663 > Logged by: Kevin.Lee > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3-beta1 > Operating system: Windows XP JP > Description:Installer: Encoding(Server) Select list have not UTF-8 > encoding. > Details: > > When I install postgresql-8.3-beta1 on my Windows XP system. When > "Initialise database cluster" windows form appear.I try to set > "Encoding(Server)" to be UTF-8. But "Encoding(Server) " select list have not > UTF-8 option. I think this may be a bug. This is a known problem. A bug creeped in just before beta, so UTF8 was disabled in the win32 binary distribution because it won't work. We are working to have this fixed by beta2. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] Fwd: BUG #3662: Seems that more than one run of a functions causes an error
Hi,
I submitted this (supposed bug) via a web form earlier, but it got back with
this bounce.
Since I was not sure whether this was accepted, so I registered with this
list and am sending this again.
Hope it helps to find the problem.
Robins
-- Forwarded message --
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Oct 9, 2007 9:20 PM
Subject: Stalled post to pgsql-bugs
To: Robins Tharakan <[EMAIL PROTECTED]>
Your message to pgsql-bugs has been delayed, and requires the approval
of the moderators, for the following reason(s):
The author ("Robins Tharakan" <[EMAIL PROTECTED]>)
is not a member of any of the restrict_post groups.
If you do not wish the message to be posted, or have other concerns,
please send a message to the list owners at the following address:
[EMAIL PROTECTED]
-- Forwarded message --
From: "Robins Tharakan" <[EMAIL PROTECTED]>
To: pgsql-bugs@postgresql.org
Date: Tue, 9 Oct 2007 15:49:53 GMT
Subject: BUG #3662: Seems that more than one run of a functions causes an
error
The following bug has been logged online:
Bug reference: 3662
Logged by: Robins Tharakan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Windows XP Professional SP2
Description:Seems that more than one run of a functions causes an
error
Details:
The situation is this. If I create a Type and create a function returning
this type, a simple select query works fine. But the same query run
immediately after, fails with an error.
This is the error I get in PgAdmin:
ERROR: could not open relation with OID 68916
SQL state: XX000
Context: PL/pgSQL function "ranked_set" line 9 at for over select rows
This is the query I am running:
SELECT * FROM ranked_set(10, ('2007-8-31'::date - interval '180
days')::date, '2007-8-31'::date);
This is the SQL for the Type and the function:
DROP FUNCTION ranked_set(integer, date, date);
DROP TYPE ranked_set_type;
CREATE TYPE ranked_set_type AS
(rank integer,
scheme_code integer,
return real);
ALTER TYPE ranked_set_type OWNER TO postgres;
CREATE OR REPLACE FUNCTION ranked_set(given_set_id integer, given_start_date
date, given_end_date date)
RETURNS SETOF ranked_set_type AS
$BODY$
DECLARE
rec ranked_set_type;
BEGIN
CREATE TEMPORARY SEQUENCE s INCREMENT BY 1 START WITH 1;
FOR rec in
(
SELECT nextval('s') as rank, tt.scheme_code, tt.ret
FROM (
SELECT
sets.scheme_code,
fund_return_in_period(sets.scheme_code, given_start_date,
given_end_date, FALSE) as ret
FROM sets
WHERE sets.set_id = given_set_id
ORDER BY ret DESC
) tt
) LOOP
RETURN NEXT rec;
END LOOP;
DROP SEQUENCE s;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
ALTER FUNCTION ranked_set(integer, date, date) OWNER TO postgres;
I tried restarting PgAdmin (1.8.0 Beta1) and repeating the steps over and
over about 4-5 times but got the exact same output.
What I didn't do as yet is restart the PG server and Vaccuum full the DB,
although the DB was vaccuumed (full) this morning without much activity
thereafter.
Hope this helps, do get back if any special tests are to be performed for
any confirmations.
Robins Tharakan
Re: [BUGS] BUG #3661: Missing equality comparator: string = integer
> > This does not function any more under PG 8.3-beta1: > > select '5'::varchar = 5; > ERROR: operator does not exist: character varying = integer > > select '5'::char = 5; > ERROR: operator does not exist: character = integer you cannot compare any character type and numeric type. If you wont to do, you have to cast to text or use function to_char or to_numeric. > > > Note that this still works: > select '5' = 5; > It is integer = integer. Value in apostrophes doesn't mean 100% char or varchar in Postgres. Pg detects unknown type (in apostrophes) accordance with know type (integer) try: postgres=# select '5.0'=5; ERROR: invalid input syntax for integer: "5a" postgres=# select '5.0'=5; ERROR: invalid input syntax for integer: "5.0" postgres=# select '5.0'=5.0; ?column? -- t (1 row) > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq > ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #3661: Missing equality comparator: string = integer
Am Dienstag, 9. Oktober 2007 schrieb David Bachmann: > This does not function any more under PG 8.3-beta1: > > select '5'::varchar = 5; > ERROR: operator does not exist: character varying = integer That is intentional. Fix your application by inserting appropriate explicit casts. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #3663: Installer: Encoding(Server) Select list have not UTF-8 encoding.
Hi. Yes, you look at the same thing as this. http://winpg.jp/~saito/pginstaller/pginstaller_8.3.beta1-error1.png I will correct it after discussion. Thanks! Regrad, Hiroshi Saito - Original Message - From: "Kevin.Lee" <[EMAIL PROTECTED]> To: Sent: Wednesday, October 10, 2007 1:05 AM Subject: [BUGS] BUG #3663: Installer: Encoding(Server) Select list have not UTF-8 encoding. The following bug has been logged online: Bug reference: 3663 Logged by: Kevin.Lee Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3-beta1 Operating system: Windows XP JP Description:Installer: Encoding(Server) Select list have not UTF-8 encoding. Details: When I install postgresql-8.3-beta1 on my Windows XP system. When "Initialise database cluster" windows form appear.I try to set "Encoding(Server)" to be UTF-8. But "Encoding(Server) " select list have not UTF-8 option. I think this may be a bug. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #3663: Installer: Encoding(Server) Select list have not UTF-8 encoding.
The following bug has been logged online: Bug reference: 3663 Logged by: Kevin.Lee Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3-beta1 Operating system: Windows XP JP Description:Installer: Encoding(Server) Select list have not UTF-8 encoding. Details: When I install postgresql-8.3-beta1 on my Windows XP system. When "Initialise database cluster" windows form appear.I try to set "Encoding(Server)" to be UTF-8. But "Encoding(Server) " select list have not UTF-8 option. I think this may be a bug. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #3662: Seems that more than one run of a functions causes an error
The following bug has been logged online:
Bug reference: 3662
Logged by: Robins Tharakan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Windows XP Professional SP2
Description:Seems that more than one run of a functions causes an
error
Details:
The situation is this. If I create a Type and create a function returning
this type, a simple select query works fine. But the same query run
immediately after, fails with an error.
This is the error I get in PgAdmin:
ERROR: could not open relation with OID 68916
SQL state: XX000
Context: PL/pgSQL function "ranked_set" line 9 at for over select rows
This is the query I am running:
SELECT * FROM ranked_set(10, ('2007-8-31'::date - interval '180
days')::date, '2007-8-31'::date);
This is the SQL for the Type and the function:
DROP FUNCTION ranked_set(integer, date, date);
DROP TYPE ranked_set_type;
CREATE TYPE ranked_set_type AS
(rank integer,
scheme_code integer,
return real);
ALTER TYPE ranked_set_type OWNER TO postgres;
CREATE OR REPLACE FUNCTION ranked_set(given_set_id integer, given_start_date
date, given_end_date date)
RETURNS SETOF ranked_set_type AS
$BODY$
DECLARE
rec ranked_set_type;
BEGIN
CREATE TEMPORARY SEQUENCE s INCREMENT BY 1 START WITH 1;
FOR rec in
(
SELECT nextval('s') as rank, tt.scheme_code, tt.ret
FROM (
SELECT
sets.scheme_code,
fund_return_in_period(sets.scheme_code, given_start_date,
given_end_date, FALSE) as ret
FROM sets
WHERE sets.set_id = given_set_id
ORDER BY ret DESC
) tt
) LOOP
RETURN NEXT rec;
END LOOP;
DROP SEQUENCE s;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
ALTER FUNCTION ranked_set(integer, date, date) OWNER TO postgres;
I tried restarting PgAdmin (1.8.0 Beta1) and repeating the steps over and
over about 4-5 times but got the exact same output.
What I didn't do as yet is restart the PG server and Vaccuum full the DB,
although the DB was vaccuumed (full) this morning without much activity
thereafter.
Hope this helps, do get back if any special tests are to be performed for
any confirmations.
Robins Tharakan
---(end of broadcast)---
TIP 6: explain analyze is your friend
[BUGS] BUG #3661: Missing equality comparator: string = integer
The following bug has been logged online: Bug reference: 3661 Logged by: David Bachmann Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3-beta1 Operating system: Windows XP Description:Missing equality comparator: string = integer Details: This does not function any more under PG 8.3-beta1: select '5'::varchar = 5; ERROR: operator does not exist: character varying = integer select '5'::char = 5; ERROR: operator does not exist: character = integer Note that this still works: select '5' = 5; ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] plpythonu execute - create function bug?
I'm not entirely sure if this is a bug. Basically I have a python
function that needs to create new functions. I intended on doing this
through the plpy.excute("create function...")
Unfortunately this crashes postmaster v8.0.3. I'm kind of bound to
this version - but it would be good to know if someone else can
replicate this error (i.e. if it's ok in other versions) or if it is
infact a bug or if I'm just doing something stupid.
A simple example:
I want to create a (plpgsql) function (an example definition as follows):
CREATE or REPLACE FUNCTION blah(inp int) RETURNS int AS $$ BEGIN
return inp; END; $$ LANGUAGE 'plpgsql';
>From a plpythonu function: that is:
CREATE OR REPLACE FUNCTION testpythonexecute() RETURNS text AS $BODY$
plpy.execute('CREATE or REPLACE FUNCTION blah(inp int) RETURNS int AS
$$ BEGIN return inp; END; $$ LANGUAGE ''plpgsql'';')
return 'done'
$BODY$
LANGUAGE 'plpythonu';
A small postmaster trace:
CONTEXT: compile of PL/pgSQL function "blah" near line 0
SQL statement "CREATE or REPLACE FUNCTION blah(inp int)
RETURNS int AS $$ BEGIN return inp; END; $$ LANGUAGE plpgsql;"
*** glibc detected *** postgres: research test [local] SELECT: free():
invalid pointer: 0xb72c83f8 ***
=== Backtrace: =
/lib/libc.so.6[0x79cdf1]
/lib/libc.so.6(cfree+0x90)[0x7a0430]
/home/research/pgsql/lib/plpython.so[0x2584c4]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x165c)[0x61d5f6c]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x63cf)[0x61dacdf]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7ef)[0x61dbb2f]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalCode+0x63)[0x61dbbb3]
/home/research/pgsql/lib/plpython.so[0x25ac2e]
/home/research/pgsql/lib/plpython.so[0x25ca77]
/home/research/pgsql/lib/plpython.so(plpython_call_handler+0xf6)[0x25cd66]
postgres: research test [local] SELECT(ExecMakeFunctionResult+0x213)[0x812b303]
postgres: research test [local] SELECT(ExecProject+0xd1)[0x81293e1]
postgres: research test [local] SELECT(ExecResult+0x5d)[0x81362dd]
postgres: research test [local] SELECT(ExecProcNode+0xdd)[0x8128b6d]
postgres: research test [local] SELECT(ExecutorRun+0x2ad)[0x812788d]
postgres: research test [local] SELECT[0x81a7480]
postgres: research test [local] SELECT(PortalRun+0x296)[0x81a8116]
postgres: research test [local] SELECT(exec_simple_query+0x20c)[0x81a41ec]
postgres: research test [local] SELECT(PostgresMain+0x1213)[0x81a5813]
postgres: research test [local] SELECT[0x8174d56]
postgres: research test [local] SELECT(PostmasterMain+0xef0)[0x81765b0]
postgres: research test [local] SELECT(main+0x22e)[0x8144dbe]
/lib/libc.so.6(__libc_start_main+0xe0)[0x74af70]
postgres: research test [local] SELECT[0x8076e01]
.
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [BUGS] libpq crash fix [was: Provide a way to not ask for a password in psql]
On Tue, Oct 09, 2007 at 04:32:02PM +0200, Martin Pitt wrote: > Hi again, > > Martin Pitt [2007-10-09 15:56 +0200]: > > (2) PGPASSFILE=/dev/null psql -l > > > >With /dev/null I get a segfault (I'll probably send a patch for > >that later). > > Ah, it tried to free(pgpassfile) in PasswordFromFile(), but that is a > local stack variable. > > Can you please apply this upstream? Applied back to 8.1 which is where it appeared. //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[BUGS] libpq crash fix [was: Provide a way to not ask for a password in psql]
Hi again,
Martin Pitt [2007-10-09 15:56 +0200]:
> (2) PGPASSFILE=/dev/null psql -l
>
>With /dev/null I get a segfault (I'll probably send a patch for
>that later).
Ah, it tried to free(pgpassfile) in PasswordFromFile(), but that is a
local stack variable.
Can you please apply this upstream?
Thanks,
Martin
--
Martin Pitthttp://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
diff -Nur postgresql-8.3/build-tree/postgresql-8.3beta1/src/interfaces/libpq/fe-connect.c postgresql-8.3.new/build-tree/postgresql-8.3beta1/src/interfaces/libpq/fe-connect.c
--- postgresql-8.3beta1/src/interfaces/libpq/fe-connect.c 2007-07-23 19:52:06.0 +0200
+++ postgresql-8.3beta1/src/interfaces/libpq/fe-connect.c 2007-10-09 16:22:41.0 +0200
@@ -3723,7 +3723,6 @@
fprintf(stderr,
libpq_gettext("WARNING: password file \"%s\" is not a plain file\n"),
pgpassfile);
- free(pgpassfile);
return NULL;
}
signature.asc
Description: Digital signature
[BUGS] Provide a way to not ask for a password in psql
Hello,
first, congratulations for 8.3beta1. I built some initial
Debian/Ubuntu packages which went very smoothly.
I am now walking through the failures of my postgresql-common test
suite. One particular regression is that there seems to be no way any
more to inhibit the password prompt in psql. This is particularly bad
for noninteractive scripts. For example, "psql -l" is a convenient
method to check whether the postmaster is running at all,
finished with startup and ready for connections.
There is a command line switch -W which forces the password prompt,
but not an inverse switch to avoid it. So those three obvious
workarounds came to my mind:
(1) psql -l < /dev/null
Does not work because simple_prompt() reads from /dev/tty.
psql could check the already existing pset.notty and not enter the
do-while loop for asking for the password if it is True.
(2) PGPASSFILE=/dev/null psql -l
With /dev/null I get a segfault (I'll probably send a patch for
that later). With an empty dummy file it cannot find a matching
password and thus prompt me again. Admittedly this behaviour does
make sense, so it should not be altered.
(3) PGPASSWORD=foo psql -l
This trick with specifying an invalid password worked up until 8.2.
Unfortunately it stopped working now due to a slight code change:
if (PQstatus(pset.db) == CONNECTION_BAD &&
- strcmp(PQerrorMessage(pset.db), PQnoPasswordSupplied) == 0 &&
+ PQconnectionUsedPassword(pset.db) &&
To get back the earlier behaviour, this could be reverted, or the
case could me made explicit with
-password == NULL &&
+password == NULL && !getenv("PGPASSWORD") &&
My current workaround is to use the dodgy patch in (3), but I'd
prefer to use an official upstream sanctioned method.
Thank you!
Martin
--
Martin Pitthttp://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
signature.asc
Description: Digital signature
Re: [BUGS] BUG #3660: unused empty file is created with csvlog
"Thomas Reiss" <[EMAIL PROTECTED]> writes: > I set the following : > log_destination = 'csvlog' > logging_collector = on > log_filename = 'postgresql-%u' > At server start, PostgreSQL creates a file called "postgresql-2" (for today) > and a file "postgresql-2.csv". This is not a bug. > File "postgresql-2" is empty and never used again, whereas > "postgresql-2.csv" contains the logs. The fact that you didn't observe anything being put into it doesn't mean that will never happen. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #3660: unused empty file is created with csvlog
The following bug has been logged online: Bug reference: 3660 Logged by: Thomas Reiss Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 beta 1 Operating system: Linux Description:unused empty file is created with csvlog Details: Hello, I just tried the csvlog logging method. I set the following : log_destination = 'csvlog' logging_collector = on log_filename = 'postgresql-%u' At server start, PostgreSQL creates a file called "postgresql-2" (for today) and a file "postgresql-2.csv". File "postgresql-2" is empty and never used again, whereas "postgresql-2.csv" contains the logs. If log_filename is set to 'postgresql-%u.csv', PostgreSQL creates two files too: postgresql-2.csv and postgresql-2.csv.csv and uses the second one. Regards, Thomas ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
