[BUGS] User-defined type name begins with the underscore character (_) can be created
Hello, pgsql-bugs. Documentation says: "User-defined type names cannot begin with the underscore character (_) and can only be 62 characters long (or in general NAMEDATALEN - 2, rather than the NAMEDATALEN - 1 characters allowed for other names). Type names beginning with underscore are reserved for internally-created array type names. " However, such SQL may be executed: CREATE TYPE _my AS (id int4, id2 int4); And server treats it as array type. Thus next SQL will be executed too: CREATE TABLE my_table( my_arr my[] ); Checked on PostgreSQL versions (Windows XP): 8.0.6 8.1.0 8.2.0 -- With best wishes, Pavel mailto:[EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[BUGS] 8.2 pl/pgsql crash bug (WAS: [pgadmin-support] Error craches pgAdmin)
The issue below was reported to us as a pgAdmin bug - it can be
recreated in psql on 8.2.0, and results in:
2006-12-12 09:06:50 LOG: server process (PID 4588) exited with exit
code -1073741819
2006-12-12 09:06:50 LOG: terminating any other active server processes
2006-12-12 09:06:50 WARNING: terminating connection because of crash of
another server process
2006-12-12 09:06:50 DETAIL: The postmaster has commanded this server
process to roll back the current transaction and exit, because another
server process exited abnormally and possibly corrupted shared memory.
2006-12-12 09:06:50 HINT: In a moment you should be able to reconnect
to the database and repeat your command.
In 8.1.5, it works as expected (ie. without crashing).
Regards, Dave.
Original Message
Subject:[pgadmin-support] Error craches pgAdmin
Date: Mon, 11 Dec 2006 20:11:39 +0100
From: Paolo Saudin <[EMAIL PROTECTED]>
To:
Hi,
I found a different pgAdmin behavior if I use it against Postgres
8.1.15 or 8.2.0. Here to try it out
I have a table filled with dates :
CREATE TABLE _master_h24 (
fulldate timestamp without time zone NOT NULL,
CONSTRAINT _master_h24_pkey PRIMARY KEY (fulldate)
) WITHOUT OIDS;
I have a function to fulfill it with dates :
CREATE OR REPLACE FUNCTION fillmastertable_h24()
RETURNS timestamp without time zone AS
$BODY$
declare
dt_now timestamp;
dt_last timestamp;
max_loops INTEGER;
v INTEGER;
BEGIN
-- gets the last update
SELECT fulldate INTO dt_last FROM _master_h24 ORDER BY fulldate DESC
LIMIT 1;
--RAISE NOTICE 'last : % ', dt_last;
-- gets the gmt - 1 hour date time
dt_now := to_timestamp(TIMEZONE('WAT',CURRENT_TIMESTAMP),
'-MM-DD');
--RAISE NOTICE 'dt_now : % ', dt_now;
max_loops := 100;
v := 0;
WHILE dt_last < dt_now AND v < max_loops loop
v := v + 1;
dt_last := dt_last + '24 HOUR'::INTERVAL;
/* execute query */
BEGIN
RAISE NOTICE 'Dt : % ', dt_last;
insert into _master_24 (fulldate) VALUES
(dt_last);/* ß <- HERE IS THE TABLE MISSPELLING
(_master_24 ) */
/* errors check */
EXCEPTION
/* in case of any error */
WHEN OTHERS THEN RAISE NOTICE 'ERROR in fillmastertable_h24';
END;
END loop;
return dt_last;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
ALTER FUNCTION fillmastertable_h24() OWNER TO postgres;
I then insert the first date to begin with :
insert into _master_h24 (fulldate) VALUES ('2006-12-01'); -> OK
I run the script :
SELECT fillmastertable_h24();
And on Postgres 8.1.15 I get back ‘ERROR: “relation _master_24” does not
exist -> OK
While on Postgres 8.2.0 I get back only “:” and pgAdmin craches loosing
the connection to the server. If I click on the server node I get the
following message box :
An error has occurred:
Server closed the connection unexpectedly
This probably means the server terminated abnormally before or while
processing the request
I don’t know if depends on pgAdmin or the server itself.
Thanks,
Paolo Saudin
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] 8.2 pl/pgsql crash bug (WAS: [pgadmin-support] Error craches
This bug seems to be introduced by this recent change to avoid memory
leakage:
Log Message:
---
Prevent intratransaction memory leak when a subtransaction is aborted
in the middle of executing a SPI query. This doesn't entirely fix the
problem of memory leakage in plpgsql exception handling, but it should
get rid of the lion's share of leakage.
Modified Files:
--
pgsql/src/backend/executor:
spi.c (r1.164 -> r1.165)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/spi.c.diff?r1=1.164&r2=1.165
I don't know that code too well, but somehow the tuptable memory context
gets messed up / not free'd properly etc.
Dave Page wrote:
The issue below was reported to us as a pgAdmin bug - it can be
recreated in psql on 8.2.0, and results in:
2006-12-12 09:06:50 LOG: server process (PID 4588) exited with exit
code -1073741819
2006-12-12 09:06:50 LOG: terminating any other active server processes
2006-12-12 09:06:50 WARNING: terminating connection because of crash of
another server process
2006-12-12 09:06:50 DETAIL: The postmaster has commanded this server
process to roll back the current transaction and exit, because another
server process exited abnormally and possibly corrupted shared memory.
2006-12-12 09:06:50 HINT: In a moment you should be able to reconnect
to the database and repeat your command.
In 8.1.5, it works as expected (ie. without crashing).
Regards, Dave.
Original Message
Subject: [pgadmin-support] Error craches pgAdmin
Date: Mon, 11 Dec 2006 20:11:39 +0100
From: Paolo Saudin <[EMAIL PROTECTED]>
To:
Hi,
I found a different pgAdmin behavior if I use it against Postgres
8.1.15 or 8.2.0. Here to try it out
I have a table filled with dates :
CREATE TABLE _master_h24 (
fulldate timestamp without time zone NOT NULL,
CONSTRAINT _master_h24_pkey PRIMARY KEY (fulldate)
) WITHOUT OIDS;
I have a function to fulfill it with dates :
CREATE OR REPLACE FUNCTION fillmastertable_h24()
RETURNS timestamp without time zone AS
$BODY$
declare
dt_now timestamp;
dt_last timestamp;
max_loops INTEGER;
v INTEGER;
BEGIN
-- gets the last update
SELECT fulldate INTO dt_last FROM _master_h24 ORDER BY fulldate DESC
LIMIT 1;
--RAISE NOTICE 'last : % ', dt_last;
-- gets the gmt - 1 hour date time
dt_now := to_timestamp(TIMEZONE('WAT',CURRENT_TIMESTAMP),
'-MM-DD');
--RAISE NOTICE 'dt_now : % ', dt_now;
max_loops := 100;
v := 0;
WHILE dt_last < dt_now AND v < max_loops loop
v := v + 1;
dt_last := dt_last + '24 HOUR'::INTERVAL;
/* execute query */
BEGIN
RAISE NOTICE 'Dt : % ', dt_last;
insert into _master_24 (fulldate) VALUES
(dt_last);/* ß <- HERE IS THE TABLE MISSPELLING
(_master_24 ) */
/* errors check */
EXCEPTION
/* in case of any error */
WHEN OTHERS THEN RAISE NOTICE 'ERROR in fillmastertable_h24';
END;
END loop;
return dt_last;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
ALTER FUNCTION fillmastertable_h24() OWNER TO postgres;
I then insert the first date to begin with :
insert into _master_h24 (fulldate) VALUES ('2006-12-01'); -> OK
I run the script :
SELECT fillmastertable_h24();
And on Postgres 8.1.15 I get back ‘ERROR: “relation _master_24” does not
exist -> OK
While on Postgres 8.2.0 I get back only “:” and pgAdmin craches loosing
the connection to the server. If I click on the server node I get the
following message box :
An error has occurred:
Server closed the connection unexpectedly
This probably means the server terminated abnormally before or while
processing the request
I don’t know if depends on pgAdmin or the server itself.
Thanks,
Paolo Saudin
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [BUGS] SPI_getvalue calls output function w/o pushing existing SPI connection + 2 extra issues
J. Greg Davidson wrote: > I have a user defined type implemented in C and SPI which has been > crashing a lot. I found a small enough case to trace the whole thing > with gdb and found that while connected to SPI I was doing a get_value > on a type T implemented in C and SPI. SPI_getvalue led to a call to T's > output routine which called SPI_connect which failed because the > previous SPI connection was still in force. The whole transaction was > aborted, so without a long gdb session I wouldn't have caught it. > Ironically the call to SPI_getvalue was in my debugging code! The question that jumps at me is why are you using SPI inside a type's output function? You should really avoid doing that. If you absolutely need to do it, enclosing the function in SPI_push/pop seems to me the least bad answer. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[BUGS] BUG #2824: Problem with installation by Remote Desktop
The following bug has been logged online: Bug reference: 2824 Logged by: Email address: pgsql-bugs@postgresql.org PostgreSQL version: 8.2 Operating system: Windows 2003 Server Description:Problem with installation by Remote Desktop Details: Message with unexpected error at end of installation, but succefully installed from local console All setting are default, including locale and encoding ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] 8.2 pl/pgsql crash bug (WAS: [pgadmin-support] Error craches
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > This bug seems to be introduced by this recent change to avoid memory > leakage: I see no crash in CVS tip --- I believe it's same bug fixed here: 2006-12-07 19:40 tgl * src/backend/executor/: spi.c (REL8_2_STABLE), spi.c: Avoid double free of _SPI_current->tuptable. AtEOSubXact_SPI() now tries to release it in a subtransaction abort, but this neglects possibility that someone outside SPI already did. Fix is for spi.c to forget about a tuptable as soon as it's handed it back to the caller. Per bug #2817 from Michael Andreen. regards, tom lane ---(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] SPI_getvalue calls output function w/o pushing existing SPI connection + 2 extra issues
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The question that jumps at me is why are you using SPI inside a type's
> output function? You should really avoid doing that.
Offhand it seems like it should work, but the real problem is that there
are probably a ton of code paths besides SPI_getvalue() that would need
to be changed to make it bulletproof. I don't have a big problem with
adding SPI_push/pop inside SPI_getvalue, but what else might need to
change?
> If you absolutely need to do it, enclosing the function in SPI_push/pop
> seems to me the least bad answer.
That would be the Wrong Thing if the function could ever be called when
*not* connected to SPI, which of course is the normal case for a type
I/O function. Correct code would be something like
bool connected = false;
if (_SPI_curid + 1 == _SPI_connected) /* connected */
{
connected = true;
SPI_push();
}
... do it ...
if (connected)
SPI_pop();
and this is only possible inside spi.c because those variables aren't
exported.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [BUGS] User-defined type name begins with the underscore character (_) can be created
Pavel Golub <[EMAIL PROTECTED]> writes: > Documentation says: > "User-defined type names cannot begin with the > underscore character (_) We've never actually enforced that AFAIK, so this might be considered a documentation bug. > CREATE TYPE _my AS (id int4, id2 int4); > > CREATE TABLE my_table( > my_arr my[] > ); You could argue that the problem there is that LookupTypeName is not verifying that what it finds is really an array of the specified type. We could make it look up the given name without modification and then apply get_array_type(), but this would mean two catalog lookups not one. Still, that might be better than possibly breaking applications that have historically worked. regards, tom lane ---(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
[BUGS] postgresql installation on centOS not working
Im not able to install postgresql-8.1.2 on CentOS 4.1 #uname -a Linux localhost.localdomain 2.6.9-11.EL #1 Wed Jun 8 16:59:52 CDT 2005 i686 i686 i386 GNU/Linux Thanks Danish ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[BUGS] ERROR: failed to build any 4-way joins
Test suite (as simple as I can produce): CREATE TABLE foo (a int, b int); INSERT INTO foo VALUES (1,2); INSERT INTO foo VALUES (2,3); INSERT INTO foo VALUES (3,3); CREATE VIEW fooview AS SELECT f1.a AS a_for_max_b FROM ( SELECT MAX(foo.b) AS MaxB FROM foo ) f2 INNER JOIN foo f1 ON f2.MaxB = f1.b; And this query fails: SELECT * FROM fooview fv1 LEFT OUTER JOIN fooview fv2 ON TRUE = TRUE; It also fails with RIGHT join, but it doesn't fail with INNER or FULL joins. If view is defined (essentially the same) as CREATE VIEW fooview AS SELECT f1.a AS a_for_max_b FROM foo f1 WHERE f1.b = (SELECT MAX(f2.b) FROM foo f2); then all is ok. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] ERROR: failed to build any 4-way joins
Sorry, versions are 8.2 & 8.3. 8.1 works well -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(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] postgresql installation on centOS not working
Danish Siddiqui wrote: Im not able to install postgresql-8.1.2 on CentOS 4.1 What's the error you're getting? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(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] ERROR: failed to build any 4-way joins
Teodor Sigaev <[EMAIL PROTECTED]> writes: > Test suite (as simple as I can produce): Mmm, sweet :-(. There is only one legal way to form the outer join, but make_rels_by_joins() doesn't try it because have_relevant_joinclause() says there is no relevant joinclause ... as indeed there is not, the "true = true" thing having been optimized away. I guess we need a hack to treat empty outer join conditions specially. > Sorry, versions are 8.2 & 8.3. 8.1 works well Right, not a problem before 8.2 because outer join order was driven by the syntax instead of by searching for a good join order. Also, you need at least two base relations on each side of the outer join, else the "last ditch" case in make_rels_by_joins() finds the join. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] postgresql installation on centOS not working
Hi, On Tue, 2006-12-12 at 19:23 +0530, Danish Siddiqui wrote: > Im not able to install postgresql-8.1.2 on CentOS 4.1 "How" it is not working? What is the error message? -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part
Re: [BUGS] BUG #2816: Logfile difference in timestamp between
Tom Lane wrote: > "Joost Karaaijeveld" <[EMAIL PROTECTED]> writes: > > Printing a timestamp using '%t%' in Windows omits the timezone in the > > logfile. In Linux the timezone is printed. Either make the two the same by > > default or make it configurable so that the user can make them the same. > > The zone name available from Windows is not only too long, but > localized, and we can't be sure that it's given in the right encoding. > So I'm afraid this isn't happening. Seems this was not documented, so I added a mention and backpatched to 8.2.X. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/config.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/config.sgml,v retrieving revision 1.98 diff -c -c -r1.98 config.sgml *** doc/src/sgml/config.sgml 30 Nov 2006 20:50:44 - 1.98 --- doc/src/sgml/config.sgml 12 Dec 2006 21:21:57 - *** *** 2803,2809 %t ! Time stamp (no milliseconds) no --- 2803,2809 %t ! Time stamp (no milliseconds, no timezone on Windows) no ---(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] ERROR: failed to build any 4-way joins
I wrote: > I guess we need a hack > to treat empty outer join conditions specially. Actually, it can happen with non-empty join conditions too, if the join condition doesn't mention the outer side; for instance, using your example explain SELECT * from fooview fv1 LEFT OUTER JOIN fooview fv2 on fv2.a_for_max_b < 10; So my original thoughts of a narrow special case for "OUTER JOIN ON TRUE" went up in smoke, and I ended up just having have_relevant_joinclause() troll for relevant outer joins all the time. This probably isn't going to cost enough planning time to matter, anyway. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
