Re: [BUGS] BUG #4625: ECPG: Memory allocation for binary data is wrong
> When using binary cursor to fetch contents of a bytea column into a variable > set to NULL, the memory allocation relies on strlen to determine the amount > of memory to allocate. If the data contains zeros, the memory allocated is > too little to store the data. And one more thank you for reporting. Fixed in CVS HEAD. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: mes...@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- 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 #4635: postgres.exe crash when RAISE NOTICE during debugging of PL/pgSQL function in PgAdminIII
The following bug has been logged online: Bug reference: 4635 Logged by: Robert Walker Email address: r.wal...@mtcworldwide.com PostgreSQL version: 8.3.5 Operating system: WinXP SP2 32-bit Description:postgres.exe crash when RAISE NOTICE during debugging of PL/pgSQL function in PgAdminIII Details: Hello, I seem to have stumbled upon a bug that is consistently reproducible on my machine. I'm running PostgreSQL 8.3.5 on WinXP SP2 32bit. I apologize if this might be a duplicate bug report, as I couldn't find anything in the TODO that seemed to match this. This is my first Postgres bug report. I also tried posted this to the bug email list, until I noticed that it mentioned I have to be a subscriber in order to use that list, so I have reposted the bug here. I have a function that basically loops through a query and uses the results from that query to do an individual insert into another table, and if there is a unique violation, it simply raises a notice and continues on. When trying to debug the function within PgAdminIII 1.8.4, when stepping through to the point of the RAISE NOTICE statement, it displays the following and then Windows informs me that postgres.exe has crashed: NOTICE: Unique constraint violation for work shift history. WARNING: terminating connection because of crash of another server process 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. HINT: In a moment you should be able to reconnect to the database and repeat your command. This is what shows in the logs in the CSV format. The pertinent line seems to be, "server process (PID 3824) was terminated by exception 0xC005". 2009-02-02 11:24:27.906 CST 4880 49872b77.1310 2 2009-02-02 11:20:55 CST 0 LOG 0 server process (PID 3824) was terminated by exception 0xC005 See C include file "ntstatus.h" for a description of the hexadecimal value. 2009-02-02 11:24:27.906 CST 4880 49872b77.1310 3 2009-02-02 11:20:55 CST 0 LOG 0 terminating any other active server processes 2009-02-02 11:24:27.906 CST postgres ed3 2104 127.0.0.1:1911 49872bac.838 2 idle 2009-02-02 11:21:48 CST Feb-00 0 WARNING 57P02 terminating connection because of crash of another server process 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. In a moment you should be able to reconnect to the database and repeat your command. 2009-02-02 11:24:27.906 CST postgres postgres 6100 127.0.0.1:1910 49872baa.17d4 2 idle 2009-02-02 11:21:46 CST Jan-00 0 WARNING 57P02 terminating connection because of crash of another server process 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. In a moment you should be able to reconnect to the database and repeat your command. 2009-02-02 11:24:27.937 CST 4880 49872b77.1310 4 2009-02-02 11:20:55 CST 0 LOG 0 all server processes terminated; reinitializing 2009-02-02 11:24:28.936 CST 4880 49872b77.1310 5 2009-02-02 11:20:55 CST 0 FATAL XX000 pre-existing shared memory block is still in use Check if there are any old server processes still running, and terminate them. Here are the table definitions and function definitions (please excuse their crudeness/bugginess, this was all in the middle of the process of learning Postgres and making some proof-of-concepts for a database, hence the use of the debugger). There would of course need to be a user login created called 'ebatt' in addition to the schema: CREATE SCHEMA ebatt AUTHORIZATION ebatt; CREATE TABLE ebatt.work_shifts ( site_id uuid NOT NULL, work_shift_label text NOT NULL, start_day_id smallint NOT NULL, start_time time without time zone NOT NULL, end_day_id smallint NOT NULL, end_time time without time zone NOT NULL, description text, CONSTRAINT work_shifts_pkey PRIMARY KEY (start_day_id, start_time, end_day_id, end_time, site_id), CONSTRAINT work_shifts_work_shift_label_key UNIQUE (work_shift_label, site_id) ) WITH (OIDS=FALSE); ALTER TABLE ebatt.work_shifts OWNER TO ebatt; CREATE TABLE ebatt.work_shift_history ( site_id uuid NOT NULL, start_day_id smallint NOT NULL, start_time time without time zone NOT NULL, end_day_id smallint NOT NULL, end_time time without time zone NOT NULL, notes text, start_timestamp timestamp with time zone NOT NULL, end_timestamp timestamp with time zone NOT NULL, CONSTRAINT work_shift_history_pkey PRIMARY KEY (start_timestamp, end_timestamp, site_id), CONSTRAINT work_shift_history_start_day_id_fkey FOREIGN KEY (start_day_id, start_time, end_day_id, end_time, site_id) REFERENCES ebatt.work_shifts (start_day_id, start_time, end_day_id, end
Re: [BUGS] BUG #4629: PL/pgSQL issue
Hello 2009/2/2 Tom Lane : > "Martin Blazek" writes: >> CREATE FUNCTION test() RETURNS integer AS $$ >> BEGIN >> CREATE RULE "rule" AS ON INSERT TO "test" DO INSTEAD INSERT INTO "test" >> VALUES (1); >> END;$$ LANGUAGE plpgsql; > > Hm, I guess nobody ever tried to do that in plpgsql before. It's > taking the INTO as starting a clause that returns values into plpgsql > variables :-(. > > There's a special case in there to prevent INTO just after INSERT > from being taken that way, but it only works when the INSERT is at > the start of the statement :-(. Guess we need to change that. > > In the meantime, you can probably work around this by using EXECUTE, > ie > We should ignore INTO keyword when statement starts with CREATE keyword. This patch have to simple. I'll prepare it. Regards Pavel Stehule > EXECUTE 'CREATE RULE "rule" AS ON INSERT TO "test" DO INSTEAD INSERT INTO > "test" VALUES (1)'; > >regards, tom lane > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs > -- 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 #4629: PL/pgSQL issue
Pavel Stehule writes:
> We should ignore INTO keyword when statement starts with CREATE
> keyword. This patch have to simple. I'll prepare it.
I'm already on it...
regards, tom lane
Index: gram.y
===
RCS file: /cvsroot/pgsql/src/pl/plpgsql/src/gram.y,v
retrieving revision 1.119
diff -c -r1.119 gram.y
*** gram.y 7 Jan 2009 13:44:37 - 1.119
--- gram.y 2 Feb 2009 19:57:59 -
***
*** 149,155
%type loop_body
%type proc_stmt pl_block
%type stmt_assign stmt_if stmt_loop stmt_while stmt_exit
! %type stmt_return stmt_raise stmt_execsql stmt_execsql_insert
%type stmt_dynexecute stmt_for stmt_perform stmt_getdiag
%type stmt_open stmt_fetch stmt_move stmt_close stmt_null
%type stmt_case
--- 149,155
%type loop_body
%type proc_stmt pl_block
%type stmt_assign stmt_if stmt_loop stmt_while stmt_exit
! %type stmt_return stmt_raise stmt_execsql
%type stmt_dynexecute stmt_for stmt_perform stmt_getdiag
%type stmt_open stmt_fetch stmt_move stmt_close stmt_null
%type stmt_case
***
*** 646,653
{ $$ = $1; }
| stmt_execsql
{ $$ = $1; }
- | stmt_execsql_insert
- { $$ = $1; }
| stmt_dynexecute
{ $$ = $1; }
| stmt_perform
--- 646,651
***
*** 1482,1508
}
;
! /* this matches any otherwise-unrecognized starting keyword */
! execsql_start : T_WORD
{ $$ = pstrdup(yytext); }
| T_ERROR
{ $$ = pstrdup(yytext); }
;
- stmt_execsql_insert : K_INSERT lno K_INTO
- {
- /*
-* We have to special-case
INSERT so that its INTO
-* won't be treated as an
INTO-variables clause.
-*
-* Fortunately, this is the
only valid use of INTO
-* in a pl/pgsql SQL command,
and INTO is already
-* a fully reserved word in the
main grammar.
-*/
- $$ = make_execsql_stmt("INSERT
INTO", $2);
- }
- ;
-
stmt_dynexecute : K_EXECUTE lno
{
PLpgSQL_stmt_dynexecute *new;
--- 1480,1494
}
;
! /* T_WORD+T_ERROR match any otherwise-unrecognized starting keyword */
! execsql_start : K_INSERT
! { $$ = pstrdup(yytext); }
! | T_WORD
{ $$ = pstrdup(yytext); }
| T_ERROR
{ $$ = pstrdup(yytext); }
;
stmt_dynexecute : K_EXECUTE lno
{
PLpgSQL_stmt_dynexecute *new;
***
*** 2156,2175
PLpgSQL_row *row = NULL;
PLpgSQL_rec *rec = NULL;
int tok;
boolhave_into = false;
boolhave_strict = false;
plpgsql_dstring_init(&ds);
plpgsql_dstring_append(&ds, sqlstart);
for (;;)
{
tok = yylex();
if (tok == ';')
break;
if (tok == 0)
yyerror("unexpected end of function definition");
! if (tok == K_INTO)
{
if (have_into)
yyerror("INTO specified more than once");
--- 2142,2177
PLpgSQL_row *row = NULL;
PLpgSQL_rec *rec = NULL;
int tok;
+ int prev_tok;
boolhave_into = false;
boolhave_strict = false;
plpgsql_dstring_init(&ds);
plpgsq
Re: [BUGS] BUG #4629: PL/pgSQL issue
2009/2/2 Tom Lane :
> Pavel Stehule writes:
>> We should ignore INTO keyword when statement starts with CREATE
>> keyword. This patch have to simple. I'll prepare it.
>
> I'm already on it...
>
>regards, tom lane
ok
Regards
Pavel Stehule
>
> Index: gram.y
> ===
> RCS file: /cvsroot/pgsql/src/pl/plpgsql/src/gram.y,v
> retrieving revision 1.119
> diff -c -r1.119 gram.y
> *** gram.y 7 Jan 2009 13:44:37 - 1.119
> --- gram.y 2 Feb 2009 19:57:59 -
> ***
> *** 149,155
> %type loop_body
> %type proc_stmt pl_block
> %type stmt_assign stmt_if stmt_loop stmt_while stmt_exit
> ! %type stmt_return stmt_raise stmt_execsql stmt_execsql_insert
> %type stmt_dynexecute stmt_for stmt_perform stmt_getdiag
> %type stmt_open stmt_fetch stmt_move stmt_close stmt_null
> %type stmt_case
> --- 149,155
> %type loop_body
> %type proc_stmt pl_block
> %type stmt_assign stmt_if stmt_loop stmt_while stmt_exit
> ! %type stmt_return stmt_raise stmt_execsql
> %type stmt_dynexecute stmt_for stmt_perform stmt_getdiag
> %type stmt_open stmt_fetch stmt_move stmt_close stmt_null
> %type stmt_case
> ***
> *** 646,653
>{ $$ = $1; }
>| stmt_execsql
>{ $$ = $1; }
> - | stmt_execsql_insert
> - { $$ = $1; }
>| stmt_dynexecute
>{ $$ = $1; }
>| stmt_perform
> --- 646,651
> ***
> *** 1482,1508
>}
>;
>
> ! /* this matches any otherwise-unrecognized starting keyword */
> ! execsql_start : T_WORD
>{ $$ = pstrdup(yytext); }
>| T_ERROR
>{ $$ = pstrdup(yytext); }
>;
>
> - stmt_execsql_insert : K_INSERT lno K_INTO
> - {
> - /*
> -* We have to special-case
> INSERT so that its INTO
> -* won't be treated as an
> INTO-variables clause.
> -*
> -* Fortunately, this is the
> only valid use of INTO
> -* in a pl/pgsql SQL command,
> and INTO is already
> -* a fully reserved word in
> the main grammar.
> -*/
> - $$ =
> make_execsql_stmt("INSERT INTO", $2);
> - }
> - ;
> -
> stmt_dynexecute : K_EXECUTE lno
>{
>PLpgSQL_stmt_dynexecute *new;
> --- 1480,1494
>}
>;
>
> ! /* T_WORD+T_ERROR match any otherwise-unrecognized starting keyword */
> ! execsql_start : K_INSERT
> ! { $$ = pstrdup(yytext); }
> ! | T_WORD
>{ $$ = pstrdup(yytext); }
>| T_ERROR
>{ $$ = pstrdup(yytext); }
>;
>
> stmt_dynexecute : K_EXECUTE lno
>{
>PLpgSQL_stmt_dynexecute *new;
> ***
> *** 2156,2175
>PLpgSQL_row *row = NULL;
>PLpgSQL_rec *rec = NULL;
>int tok;
>boolhave_into = false;
>boolhave_strict = false;
>
>plpgsql_dstring_init(&ds);
>plpgsql_dstring_append(&ds, sqlstart);
>
>for (;;)
>{
>tok = yylex();
>if (tok == ';')
>break;
>if (tok == 0)
>yyerror("unexpected end of function definition");
> ! if (tok == K_INTO)
>{
>if (have_into)
>yyerror("INTO specified more than once");
> --- 2142,2177
>PLpgSQL_row *row = NULL;
>PLpgSQL_rec *rec = NULL;
>int tok;
> + int
Re: [BUGS] BUG #4635: postgres.exe crash when RAISE NOTICE during debugging of PL/pgSQL function in PgAdminIII
"Robert Walker" writes: > I have a function that basically loops through a query and uses the results > from that query to do an individual insert into another table, and if there > is a unique violation, it simply raises a notice and continues on. When > trying to debug the function within PgAdminIII 1.8.4, when stepping through > to the point of the RAISE NOTICE statement, it displays the following and > then Windows informs me that postgres.exe has crashed: I suppose this is a bug in the plpgsql debugger; which you'll need to report to EDB. The core postgres project does not maintain that code. regards, tom lane -- 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 #4636: dump/restore of table inheritance fails with serial colums
The following bug has been logged online:
Bug reference: 4636
Logged by: Shane Caraveo
Email address: sha...@activestate.com
PostgreSQL version: 8.3.5
Operating system: osx 10.5 and linux
Description:dump/restore of table inheritance fails with serial
colums
Details:
Given two tables with inheritance:
CREATE TABLE child
(
id serial NOT NULL,
)
CREATE TABLE parent
(
id serial NOT NULL,
)
-- alter table done at some point after table creation
ALTER TABLE child INHERIT parent;
When I pg_dump and restore (using psql < dump_file), the sequence for the id
column in the child table points to the sequence of the parent, rather than
it's own, in pgadmin I see:
CREATE TABLE child
(
id integer NOT NULL DEFAULT nextval('parent_id_seq'::regclass),
...
)
Using the following fixes the problem, pg_dump should handle this somehow.
ALTER TABLE child
ALTER COLUMN id DROP DEFAULT,
ALTER COLUMN id SET DEFAULT nextval('child_id_seq'::regclass);
The closest reference I could find to this bug is in
http://archives.postgresql.org/pgsql-bugs/2007-11/msg00246.php
However, this is still happening in 8.3.5 on both osx and linux.
--
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 #4629: PL/pgSQL issue
"Martin Blazek" writes: > CREATE FUNCTION test() RETURNS integer AS $$ > BEGIN > CREATE RULE "rule" AS ON INSERT TO "test" DO INSTEAD INSERT INTO "test" > VALUES (1); > END;$$ LANGUAGE plpgsql; Hm, I guess nobody ever tried to do that in plpgsql before. It's taking the INTO as starting a clause that returns values into plpgsql variables :-(. There's a special case in there to prevent INTO just after INSERT from being taken that way, but it only works when the INSERT is at the start of the statement :-(. Guess we need to change that. In the meantime, you can probably work around this by using EXECUTE, ie EXECUTE 'CREATE RULE "rule" AS ON INSERT TO "test" DO INSTEAD INSERT INTO "test" VALUES (1)'; regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: *****SPAM***** [BUGS] BUG #4623: %s pattern broken in PGTYPEStimestamp_defmt_asc
Sorry, for the long time before I answer, but this email, like others, was caught by my spam filter. Spamassassin doesn't like mail hubs calling themselves localhost. Sigh. > Support for %s format is broken in PGTYPEStimestamp_defmt_asc. Fixed in CVS HEAD. Thanks for the report. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: mes...@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
