[BUGS] create temporary sequence and ecpg
POSTGRESQL BUG REPORT TEMPLATE
Your name : Edmund Bacon
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : Intel Pentium
Operating System (example: Linux 2.0.26 ELF) : Linux 2.4.20
PostgreSQL version (example: PostgreSQL-7.3.4): PostgreSQL-7.3.4
Compiler used (example: gcc 2.95.2) : gcc 3.2.2
Please enter a FULL description of your problem:
Trying to create a TEMPORARY SEQUENCE with ecpg produces
a runtime erorr. the sqlprint error is:
sql error 'ERROR: parser: parse error at or near "foo" at character 27'
in lin
A workaround is to use EXECUTE IMMEDIATE
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
exec sql include sqlca;
$ cat tmpseq.pgc
int main()
{
exec sql whenever sqlerror sqlprint;
exec sql connect to test;
exec sql create temporary sequence foo;
exec sql disconnect;
return 0;
}
Looking at the emitted C code we see:
{ ECPGdo(__LINE__, NULL, "create sequence temporary foo ", ECPGt_EOIT,
ECPGt_EORT);
Note that the tokens "sequence" and "temporary" have been reversed.
If you know how this problem might be fixed, list the solution below:
-----
--
Edmund Bacon <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
[BUGS] ECPG and NULL indicators
POSTGRESQL BUG REPORT
Your name : Edmund Bacon
Your email address : ebacon (at) onesystem (dot) com
System Configuration
-
Architecture : Intel Pentium
Operating System : Linux 2.4.20
PostgreSQL version : PostgreSQL-7.3.3
Compiler used : gcc-3.2.2
Please enter a FULL description of your problem:
ecpg does not correctly set null indicators when storage for the
string is dynamically allocated
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
CREATE TABLE strings (string text);
insert into strings values('able');
insert into strings values(null);
insert into strings values('baker');
insert into strings values(null);
Source for foo.pgc:
#include
#include
#include
EXEC SQL WHENEVER SQLERROR sqlprint;
EXEC SQL INCLUDE sqlca;
int main()
{
int i;
EXEC SQL BEGIN DECLARE SECTION;
char **a_str;
int *a_str_ind;
char str[5][20];
int str_ind[5];
EXEC SQL END DECLARE SECTION;
EXEC SQL CONNECT TO test;
printf("Test one: alloced string, allocated indicator:\n");
a_str = NULL;
a_str_ind = NULL;
EXEC SQL SELECT string INTO :a_str :a_str_ind FROM strings;
printf("indicator string\n");
for(i = 0; i < sqlca.sqlerrd[2]; i++)
printf("%8d \"%s\"\n", a_str_ind[i], a_str[i]);
free(a_str);
free(a_str_ind);
printf("\nTest two: alloced string, unalloced indicator:\n");
a_str = NULL;
for(i = 0; i < 5; i++) str_ind[i] = 99;
EXEC SQL SELECT string INTO :a_str :str_ind FROM strings;
printf("indicator string\n");
for(i = 0; i < sqlca.sqlerrd[2]; i++)
printf("%8d \"%s\"\n", str_ind[i], a_str[i]);
free(a_str);
printf("\nTest three: unalloced string, alloced indicator:\n");
a_str_ind = NULL;
bzero(str, sizeof(str));
EXEC SQL SELECT string INTO :str :a_str_ind FROM strings;
printf("indicator string\n");
for(i = 0; i < sqlca.sqlerrd[2]; i++)
printf("%8d \"%s\"\n", a_str_ind[i], str[i]);
free(a_str_ind);
printf("\nTest four: unalloced string, unalloced indicator:\n");
bzero(str, sizeof(str));
for(i = 0; i < 5; i++) str_ind[i] = 99;
EXEC SQL SELECT string INTO :str :str_ind FROM strings;
printf("indicator string\n");
for(i = 0; i < sqlca.sqlerrd[2]; i++)
printf("%8d \"%s\"\n", str_ind[i], str[i]);
return 0;
}
==
Output for foo:
==
Test one: alloced string, allocated indicator:
indicator string
-1 "able"
0 ""
0 "baker"
0 ""
Test two: alloced string, unalloced indicator:
indicator string
-1 "able"
99 ""
99 "baker"
99 ""
Test three: unalloced string, alloced indicator:
indicator string
0 "able"
-1 ""
0 "baker"
-1 ""
Test four: unalloced string, unalloced indicator:
indicator string
0 "able"
-1 ""
0 "baker"
-1 ""
==
Note that when the storage for the string is allocated, only the first
element of the indicator array is set. This value is the value of
the indicator for the last string in the string array, which can be
confirmed by using the appropriate ORDER BY clause.
This problem does not arise with allocated integer or float values.
This problem occurs if string is any multi-char type (e.g. TEXT, CHAR(),
or VARCHAR())
---(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] PostgreSQL Patch: Test-and-set routine for HP-UX
I am unable to get this patch to compile: gcc version : gcc (GCC) 3.2 20020329 (experimental) uname -srm : HP-UX B.11.22 ia64 tar xvf postgresql-7.3.4.tar cd postgresql-7.3.4 patch -p0 ../PostgreSQL-7.3.4_hpux3_11iv2_IA-64.patch ./configure [snip] make [snip] gmake[4]: Entering directory `/home/postgres/src/postgresql-7.3.4/src/backend/ac cess/transam' gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/incl ude -c -o xlog.o xlog.c xlog.c: In function `XLogInsert': xlog.c:641: incompatible types in assignment xlog.c:870: incompatible types in assignment xlog.c: In function `AdvanceXLInsertBuffer': xlog.c:929: incompatible types in assignment xlog.c: In function `XLogWrite': xlog.c:1189: incompatible types in assignment xlog.c: In function `XLogFlush': xlog.c:1248: incompatible types in assignment xlog.c: In function `XLOGShmemInit': xlog.c:2361: incompatible types in assignment xlog.c: In function `GetRedoRecPtr': xlog.c:2918: incompatible types in assignment xlog.c: In function `CreateCheckPoint': xlog.c:3068: incompatible types in assignment gmake[4]: *** [xlog.o] Error 1 gmake[4]: Leaving directory `/home/postgres/src/postgresql-7.3.4/src/backend/acc ess/transam' gmake[3]: *** [transam-recursive] Error 2 This seems to be a problem with SpinLockRelease_NoHoldoff. On Fri, 2003-10-24 at 11:51, ViSolve Open Source Team wrote: > Subject: PostgreSQL Patch: Test-and-set routine for HP-UX (IA-64) > > > Hello, > > The attached patch provides a test-and-set routine for PostgreSQL for HP-UX > 11iV2 for the Intel Itanium architecture (known to the PostgreSQL code as > IA-64). There are actually two issues: > > 1. There is currently no tas (test-and-set) routine for HP-UX IA-64 in the > s_lock.h header file. > 2. In HP-UX IA-64, the suffix of shared libraries is ".so", but PostgreSQL > generates a ".sl" suffix. > > The attached patch fixes both issues. The bug template (also attached) > contains the details. > > We (ViSolve) are a group that works closely with HP on their OpenSource > initiative. We would really appreciate a timely inclusion of this patch > into mainstream PostgreSQL. > > thanks > ViSolve OpenSource Team (for HP) > > __ > ---(end of broadcast)--- > TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 3: 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
[BUGS] 8.0 beta1: pg_dump/restore failing
pg_dump/restore in 8.0beta1 are not working well with formats other thans plain text: $ pg_restore --version pg_restore (PostgreSQL) 8.0.0beta1 $ pg_dump --version pg_dump (PostgreSQL) 8.0.0beta1 $ createdb test_8 CREATE DATABASE $ createlang plpgsql test_8 $ psql test_8 -c \ > " create function foo() returns int as 'begin return 1; end;' language 'plpgsql'" CREATE FUNCTION $ psql test_8 -c "select foo()"; foo - 1 (1 row) $ pg_dump --format=c --file=test_8.dump test_8 $ pg_restore --format=c --clean --dbname=test_8 test_8.dump pg_restore: [archiver (db)] could not execute query: ERROR: schema "public" does not exist pg_restore: [archiver (db)] could not execute query: ERROR: schema "public" does not exist pg_restore: [archiver (db)] could not execute query: ERROR: schema "public" does not exist pg_restore: [archiver (db)] could not execute query: ERROR: unterminated dollar-quoted string at or near "$$begin return 1;" at character 115 pg_restore: WARNING: there is no transaction in progress pg_restore: [archiver (db)] could not execute query: ERROR: unterminated dollar-quoted string at or near "$$ LANGUAGE plpgsql;" at character 1 pg_restore: [archiver (db)] could not execute query: ERROR: schema "public" does not exist pg_restore: [archiver (db)] could not execute query: ERROR: schema "public" does not exist pg_restore: [archiver (db)] could not execute query: ERROR: schema "public" does not exist pg_restore: [archiver (db)] could not execute query: ERROR: schema "public" does not exist pg_restore: [archiver (db)] could not execute query: ERROR: schema "public" does not exist -- -- PostgreSQL database dump complete -- WARNING, errors ignored on restore: 10 $ Note that there was a problem restoring the function. Did --clean remove the public schema? Hmm ... maybe there's a problem with --clean $ dropdb test_8 DROP DATABASE $ pg_restore --format=c --create --dbname=test test_8.dump pg_restore: [archiver (db)] could not execute query: ERROR: unterminated dollar-quoted string at or near "$$begin return 1;" at character 115 pg_restore: WARNING: there is no transaction in progress pg_restore: [archiver (db)] could not execute query: ERROR: unterminated dollar-quoted string at or near "$$ LANGUAGE plpgsql;" at character 1 pg_restore: [archiver (db)] could not execute query: ERROR: function public.foo() does not exist -- -- PostgreSQL database dump complete -- WARNING, errors ignored on restore: 3 $ Yep, but we still can't restore the function. tests with format=t show the same behaviour. tests with format=p succeed -- Edmund Bacon <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] 8.0 beta1: pg_dump/restore failing
Yes. My appologies for the poor bug report. I have tried this on RedHat 9, gcc 3.2.2 x86 and HP-UX 10.20 gcc 3.2.3 pa-risc The problem is that pg_restore is not correctly recognizing the ending $$ quotes on functions: Note that in the pg_restore text output at the bottom of the message, the closing $$ quotes are there, but pg_restore using the custom format (or tar format) doesn't recognize them. Doing a strings -a on test.dump also shows the closing $$ quotes. e.g. # -- start with a fresh database: $ createdb test CREATE DATABASE # -- do a restore $ pg_restore --format=c --dbname=test test.dump pg_restore: [archiver (db)] could not execute query: ERROR: unterminated dollar -quoted string at or near "$$begin return 1;" at character 115 pg_restore: WARNING: there is no transaction in progress pg_restore: [archiver (db)] could not execute query: ERROR: unterminated dollar -quoted string at or near "$$ LANGUAGE plpgsql;" at character 1 pg_restore: [archiver (db)] could not execute query: ERROR: function public.foo () does not exist -- -- PostgreSQL database dump complete -- WARNING, errors ignored on restore: 3 # -- try again with fresh database, but use psql and output from pg_dump $ dropdb test DROP DATABASE $ createdb test CREATE DATABASE $ pg_restore test.dump | psql test -f - SET SET COMMENT SET CREATE FUNCTION ALTER FUNCTION CREATE FUNCTION ALTER FUNCTION CREATE LANGUAGE CREATE FUNCTION ALTER FUNCTION REVOKE REVOKE GRANT GRANT $ -- and here is the pg_restore output $ pg_restore test.dump -- -- PostgreSQL database dump -- [ ### snip creating language plpgsql, etc ### ] -- -- Name: foo(); Type: FUNCTION; Schema: public; Owner: ebacon -- CREATE FUNCTION foo() RETURNS integer AS $$begin return 1; end;$$ LANGUAGE plpgsql; ALTER FUNCTION public.foo() OWNER TO ebacon; -- -- Name: public; Type: ACL; Schema: -; Owner: postgres -- REVOKE ALL ON SCHEMA public FROM PUBLIC; REVOKE ALL ON SCHEMA public FROM postgres; GRANT ALL ON SCHEMA public TO postgres; GRANT ALL ON SCHEMA public TO PUBLIC; -- -- PostgreSQL database dump complete -- $ Tom Lane wrote: Edmund Bacon <[EMAIL PROTECTED]> writes: pg_dump/restore in 8.0beta1 are not working well with formats other thans plain text: What seems to be broken is --clean mode, because it drops and fails to restore the public schema. I can see no reason that it wouldn't work exactly the same regardless of dump format though. Are you sure you didn't get confused because things were already broken once the destination DB's public schema was gone? regards, tom lane -- Edmund Bacon <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] BUG #1440: ecpg seg faults
The following bug has been logged online:
Bug reference: 1440
Logged by: Edmund Bacon
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.0
Operating system: Linux Redhat 9 Pentium-4
Description:ecpg seg faults
Details:
I have here a shortish source file that produces a seg-fault from ecpg.
$ ecpg --version
ecpg (PostgreSQL 8.0.0) 3.2.0
$ cat test_bad.pgc
#include
EXEC SQL INCLUDE sqlca;
typedef
struct ideal_fc {
int upc;
char code[7];
doube usage_x;
int used;
} IDEAL_FOOD_COST;
void save_ideal_adv(char *bus_date, IDEAL_FOOD_COST *Ideal, int session_id)
{
int i, j;
EXEC SQL TYPE SQL_IDEAL IS
struct sql_ideal {
int ph_id;
double quantity;
char code[8];
};
EXEC SQL BEGIN DECLARE SECTION;
SQL_IDEAL sql_Ideal;
char *sql_date;
EXEC SQL END DECLARE SECTION;
EXEC SQL SELECT prod_hist_id, quantity, code
INTO :sql_Ideal
FROM product_history
JOIN products USING(upc)
WHERE trans_key = -2 AND date(date) = date(:sql_date)
ORDER BY code;
}
void insert_ideal(char *date, IDEAL_FOOD_COST *fc, int session_id)
{
EXEC SQL BEGIN DECLARE SECTION;
int upx;
double qty;
char *dt = date;
int sess_id = session_id;
EXEC SQL END DECLARE SECTION;
EXEC SQL
INSERT INTO product_history(date, upc, session_id, quantity,
trans_key)
VALUES(:dt, :upx, :sess_id, :qty, -2);
}
$ ecpg test_bad.pgc
Segmentation fault (core dumped)
$
Note that the following source file, which differs only in the order of the
functions passes ecpg without error.
$ cat test_good.pgc
#include
EXEC SQL INCLUDE sqlca;
typedef
struct ideal_fc {
int upc;
char code[7];
doube usage_x;
int used;
} IDEAL_FOOD_COST;
void insert_ideal(char *date, IDEAL_FOOD_COST *fc, int session_id)
{
EXEC SQL BEGIN DECLARE SECTION;
int upx;
double qty;
char *dt = date;
int sess_id = session_id;
EXEC SQL END DECLARE SECTION;
EXEC SQL
INSERT INTO product_history(date, upc, session_id, quantity,
trans_key)
VALUES(:dt, :upx, :sess_id, :qty, -2);
}
void save_ideal_adv(char *bus_date, IDEAL_FOOD_COST *Ideal, int session_id)
{
int i, j;
EXEC SQL TYPE SQL_IDEAL IS
struct sql_ideal {
int ph_id;
double quantity;
char code[8];
};
EXEC SQL BEGIN DECLARE SECTION;
SQL_IDEAL sql_Ideal;
char *sql_date;
/*int phist_id;
double qty;
int SESSION_ID; */
EXEC SQL END DECLARE SECTION;
EXEC SQL SELECT prod_hist_id, quantity, code
INTO :sql_Ideal
FROM product_history
JOIN products USING(upc)
WHERE trans_key = -2 AND date(date) = date(:sql_date)
ORDER BY code;
}
$ ecpg test_good.pgc
$ echo $?
0
Both source files pass with ecpg v 3.1.1 (Posgtresql 7.4.2) on RedHat Linux
9 (x86), and (interstingly) withe ecpg v 3.2.0 (Postgres 8.0.) under HPUX
11i - ia64
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] BUG #1440: ecpg seg faults
According to the backtrace, it appears to be dieing in malloc. (gdb) bt #0 0x40149f9c in _int_malloc () from /lib/i686/libc.so.6 #1 0x40149201 in malloc () from /lib/i686/libc.so.6 #2 0x080547c3 in mm_alloc (size=3) at type.c:13 #3 0x080493a0 in make_str (str=0x4020c400 "\001") at preproc.y:129 #4 0x0804f629 in yyparse () at preproc.y:4899 #5 0x08055db0 in main (argc=2, argv=0xbfffdb94) at ecpg.c:424 #6 0x400eba67 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) Michael Fuhr wrote: On Mon, Jan 24, 2005 at 12:08:36PM -0700, Michael Fuhr wrote: ecpg in free(): warning: chunk is already free If you have a core dump then maybe you can do a backtrace and see where that's happening. This assumes, perhaps prematurely, that the free() problem is causing the core dump on your platform. In any case, a backtrace should help track down the problem. -- Edmund Bacon <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] BUG #1440: ecpg seg faults
You know, I should have been able to think of that: njamd says: (gdb) set env LD_PRELOAD=libnjamd.so (gdb) set env NJAMD_CHK_FREE=error (gdb) r test_bad.pgc Starting program: /var/lib/pgsql/src/postgresql-8.0.0/src/interfaces/ecpg/preproc/ecpg test_bad.pgc NJAMD/free: Double free of address 0x41454ff4 Program received signal SIGSEGV, Segmentation fault. 0x4010a671 in kill () from /lib/i686/libc.so.6 (gdb) bt #0 0x4010a671 in kill () from /lib/i686/libc.so.6 #1 0x4010a405 in raise () from /lib/i686/libc.so.6 #2 0x4001f867 in __nj_underflow_free () from /usr/lib/libnjamd.so #3 0x4001fe93 in __nj_overflow_free () from /usr/lib/libnjamd.so #4 0x40021e87 in free () from /usr/lib/libnjamd.so #5 0x0805755f in remove_typedefs (brace_level=1073902784) at variable.c:271 #6 0x08049e02 in yyparse () at preproc.y:610 #7 0x08055db0 in main (argc=2, argv=0xbfffe254) at ecpg.c:424 #8 0x400f7a67 in __libc_start_main () from /lib/i686/libc.so.6 Tom Lane wrote: Edmund Bacon <[EMAIL PROTECTED]> writes: According to the backtrace, it appears to be dieing in malloc. That's consistent with the idea that the multiple free is the source of trouble --- multiple free() could corrupt malloc's private data structures to the point of causing a crash in a later malloc call. The least painful way of locating the problem would be to relink ecpg with a debugging malloc package, which could tell you exactly where the bad free() call is. You'd probably want to rebuild with --enable-debug too. regards, tom lane ---(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 -- Edmund Bacon <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 8: explain analyze is your friend
