Re: [HACKERS] pg_regress inputdir
Alvaro Herrera wrote:
In my opinion, the need
for running tests outside the test dir is not very strong (or we would
have heard complaints before), and thus the solution is to remove
--inputdir and --outputdir.
Attached is a patch that removes --inputdir and --outputdir. I still
prefere the first patch (that fixed my problem), but removing them is
probably better than having them when they don't work.
Tested with psql make check on solaris x86.
-J
--
Jørgen Austvik, Software Engineering - QA
Sun Microsystems Database Group
Index: src/test/regress/pg_regress_main.c
===
RCS file: /projects/cvsroot/pgsql/src/test/regress/pg_regress_main.c,v
retrieving revision 1.3
diff -u -r1.3 pg_regress_main.c
--- src/test/regress/pg_regress_main.c 1 Jan 2008 19:46:00 - 1.3
+++ src/test/regress/pg_regress_main.c 4 Aug 2008 11:19:04 -
@@ -34,12 +34,9 @@
char expectfile[MAXPGPATH];
char psql_cmd[MAXPGPATH * 3];
- snprintf(infile, sizeof(infile), %s/sql/%s.sql,
- inputdir, testname);
- snprintf(outfile, sizeof(outfile), %s/results/%s.out,
- outputdir, testname);
- snprintf(expectfile, sizeof(expectfile), %s/expected/%s.out,
- inputdir, testname);
+ snprintf(infile, sizeof(infile), sql/%s.sql, testname);
+ snprintf(outfile, sizeof(outfile), results/%s.out, testname);
+ snprintf(expectfile, sizeof(expectfile), expected/%s.out, testname);
add_stringlist_item(resultfiles, outfile);
add_stringlist_item(expectfiles, expectfile);
Index: src/test/regress/pg_regress.c
===
RCS file: /projects/cvsroot/pgsql/src/test/regress/pg_regress.c,v
retrieving revision 1.46
diff -u -r1.46 pg_regress.c
--- src/test/regress/pg_regress.c 3 Aug 2008 05:12:38 - 1.46
+++ src/test/regress/pg_regress.c 4 Aug 2008 11:19:04 -
@@ -32,6 +32,9 @@
#include getopt_long.h
#include pg_config_paths.h
+#define LOG_DIRECTORY log
+#define RESULTS_DIRECTORY results
+
/* for resultmap we need a list of pairs of strings */
typedef struct _resultmap
{
@@ -68,8 +71,6 @@
/* options settable from command line */
_stringlist *dblist = NULL;
bool debug = false;
-char *inputdir = .;
-char *outputdir = .;
char *psqldir = NULL;
static _stringlist *loadlanguage = NULL;
static int max_connections = 0;
@@ -560,8 +561,7 @@
FILE *f;
/* scan the file ... */
- snprintf(buf, sizeof(buf), %s/resultmap, inputdir);
- f = fopen(buf, r);
+ f = fopen(resultmap, r);
if (!f)
{
/* OK if it doesn't exist, else complain */
@@ -1702,8 +1702,7 @@
FILE *difffile;
/* create the log file (copy of running status output) */
- snprintf(file, sizeof(file), %s/regression.out, outputdir);
- logfilename = strdup(file);
+ logfilename = regression.out;
logfile = fopen(logfilename, w);
if (!logfile)
{
@@ -1713,8 +1712,7 @@
}
/* create the diffs file as empty */
- snprintf(file, sizeof(file), %s/regression.diffs, outputdir);
- difffilename = strdup(file);
+ difffilename = regression.diffs;
difffile = fopen(difffilename, w);
if (!difffile)
{
@@ -1726,9 +1724,8 @@
fclose(difffile);
/* also create the output directory if not present */
- snprintf(file, sizeof(file), %s/results, outputdir);
- if (!directory_exists(file))
- make_directory(file);
+ if (!directory_exists(RESULTS_DIRECTORY))
+ make_directory(RESULTS_DIRECTORY);
}
static void
@@ -1799,14 +1796,12 @@
printf(_(Options:\n));
printf(_( --dbname=DB use database DB (default \regression\)\n));
printf(_( --debug turn on debug mode in programs that are run\n));
- printf(_( --inputdir=DIRtake input files from DIR (default \.\)\n));
printf(_( --load-language=lang load the named language before running the\n));
printf(_(tests; can appear multiple times\n));
printf(_( --create-role=ROLEcreate the specified role before testing\n));
printf(_( --max-connections=N maximum number of concurrent connections\n));
printf(_((default is 0 meaning unlimited)\n));
printf(_( --multibyte=ENCODING use ENCODING as the multibyte encoding\n));
- printf(_( --outputdir=DIR place output files in DIR (default \.\)\n));
printf(_( --schedule=FILE use test ordering schedule from FILE\n));
printf(_((can be used multiple times to concatenate)\n));
printf(_( --srcdir=DIR absolute path to source directory (for VPATH builds)\n));
@@ -1844,11 +1839,9 @@
{version, no_argument, NULL, 'V'},
{dbname, required_argument, NULL, 1},
{debug, no_argument, NULL, 2},
- {inputdir, required_argument, NULL, 3},
{load-language, required_argument, NULL, 4},
{max-connections, required_argument, NULL, 5},
{multibyte, required_argument, NULL, 6},
- {outputdir, required_argument, NULL, 7},
{schedule, required_argument, NULL, 8},
Re: [HACKERS] pg_regress inputdir
Alvaro Herrera wrote: Jorgen Austvik - Sun Norway wrote: The attached patch makes pg_regress write converted files to inputdir/sql and inputdir/expected, which is one way to make it read and write to the same directory. Tested on Solaris x86 with pgsql make check and standalone. I think this breaks VPATH builds in both letter and spirit. Letter: 8---8---8---8---8---8--- bash-3.2$ ggrep -R \-\-inputdir * src/test/regress/pg_regress.c: printf(_( --inputdir=DIR take input files from DIR (default \.\)\n)); Binary file src/test/regress/pg_regress.o matches Binary file src/test/regress/pg_regress matches Binary file src/test/regress/tmp_check/install/usr/local/pgsql/lib/pgxs/src/test/regress/pg_regress matches 8---8---8---8---8---8--- Since it is not used in PostgreSQL build (only default value - .), I have problems seeing how writing to e.g. ./sql/file instead of writing to sql/file could break anything. Please explain. Spirit: Nobody has ever accuse me of being spiritual ;-), but if you have a URI that explains the VPATH spirit, I'd be interested to read about it. Why do you need this anyway? I tried to explain that in the first mail, but let me try again. Use case: Running pg_regress outside of PostgreSQL build system. pg_regress is installed in e.g. /usr/postgres/8.3/bin/, input, output, sql and expected are installed in some other path, e.g. /usr/postgres/8.3/share/test. User is in ~ and tries to run the PostgreSQL regression tests. It doesn't work, in fact the only way to make it work is to cd to the parent directory of sql and expected. Today, using --inputdir in pg_regress does not work for any other value than something that resolves to cwd, since it will write a file to ./sql, but try to read the same file from inputdir/sql. -J -- Jørgen Austvik, Software Engineering - QA Sun Microsystems Database Group http://blogs.sun.com/austvik/ http://www.austvik.net/ begin:vcard fn;quoted-printable:J=C3=B8rgen Austvik n;quoted-printable:Austvik;J=C3=B8rgen org:Sun Microsystems;Database Group adr:;;Haakon VII gt. 7b;Trondheim;;NO-7485;Norway email;internet:[EMAIL PROTECTED] title:Senior Engineer tel;work:+47 73 84 21 10 tel;fax:+47 73 84 21 01 tel;cell:+47 901 97 886 note:http://www.austvik.net/ x-mozilla-html:FALSE url:http://blogs.sun.com/austvik/ version:2.1 end:vcard -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_regress inputdir
Alvaro Herrera wrote: Today, using --inputdir in pg_regress does not work for any other value than something that resolves to cwd, since it will write a file to ./sql, but try to read the same file from inputdir/sql. Maybe I'm missing something, but I don't see any reason why this is a scenario worth supporting. What's the problem with cd'ing into the directory containing the tests? I agree - cd or some symlinks to cover up that the --inputdir parameter does not work if you set it to anything except the default is a workaround. Do we also agree that if you set --inputdir to anything other than the default, pg_regress will not work (will write a file to one folder, and try to read the same file from another)? And if we agree above - should we make setting --inputdir work (read and write from/to same directory), remove the --inputdir parameter (since setting it to anything different from default value doesn't work), or keep it there (to confuse people)? -J -- Jørgen Austvik, Software Engineering - QA Sun Microsystems Database Group begin:vcard fn;quoted-printable:J=C3=B8rgen Austvik n;quoted-printable:Austvik;J=C3=B8rgen org:Sun Microsystems;Database Group adr:;;Haakon VII gt. 7b;Trondheim;;NO-7485;Norway email;internet:[EMAIL PROTECTED] title:Senior Engineer tel;work:+47 73 84 21 10 tel;fax:+47 73 84 21 01 tel;cell:+47 901 97 886 note:http://www.austvik.net/ x-mozilla-html:FALSE url:http://blogs.sun.com/austvik/ version:2.1 end:vcard -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_regress inputdir
Hi, with regards to --inputdir, --srcdir, --outputdir and --schedule, pg_regress does something like this: convert files in srcdir/input, and place them in ./sql convert files in srcdir/output, and place them in ./expected read schedule from schedule for each test in schedule: read test from inputdir/sql/testname.sql read expected result from inputdir/expected/testname.out write results to outputdir/results/testname.out My problem when running pg_regress standalone, is that converted files are written to e.g. ./sql, but read from e.g. inputdir/sql, which makes the --inputdir parameter pretty unusable if it is set to something different from some path leading to cwd. Illustrated with code: Writing converted source file (pg_regress.s:493): snprintf(destfile, MAXPGPATH, %s/%s.%s, dest, prefix, suffix); (Where dest is sql or expected.) Reading files (pg_regress_main.c:37+38): snprintf(infile, sizeof(infile), %s/sql/%s.sql, inputdir, testname); The attached patch makes pg_regress write converted files to inputdir/sql and inputdir/expected, which is one way to make it read and write to the same directory. Tested on Solaris x86 with pgsql make check and standalone. -J -- Jørgen Austvik, Software Engineering - QA Sun Microsystems Database Group http://blogs.sun.com/austvik/ http://www.austvik.net/ Index: src/test/regress/pg_regress.c === RCS file: /projects/cvsroot/pgsql/src/test/regress/pg_regress.c,v retrieving revision 1.45 diff -u -r1.45 pg_regress.c --- src/test/regress/pg_regress.c 17 May 2008 20:02:01 - 1.45 +++ src/test/regress/pg_regress.c 29 Jul 2008 12:36:38 - @@ -490,7 +490,7 @@ /* build the full actual paths to open */ snprintf(prefix, strlen(*name) - 6, %s, *name); snprintf(srcfile, MAXPGPATH, %s/%s, indir, *name); - snprintf(destfile, MAXPGPATH, %s/%s.%s, dest, prefix, suffix); + snprintf(destfile, MAXPGPATH, %s/%s/%s.%s, inputdir, dest, prefix, suffix); infile = fopen(srcfile, r); if (!infile) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_regress: referencing shared objects from tests
Tom Lane wrote: Jorgen Austvik - Sun Norway [EMAIL PROTECTED] writes: we would like to be able to use and ship pg_regress and the PostgreSQL test suite independently of the PostgreSQL build environment, for testing and maybe even as a separate package to be build and shipped with the OS for others to test their setup. Does this sound like a sane and OK thing to do? The RPM packages have done this since approximately forever. You might want to look at the patches used there. Hi, yes [1] is the same that we have been using internally. Let me reformulate my question: would it be better to include something like the attached patch in PostgreSQL, than have every distributor of the tests apply it? [1] http://cvs.fedoraproject.org/viewcvs/rpms/postgresql/F-9/postgresql-test.patch?rev=1.3view=auto -J -- Jørgen Austvik, Software Engineering - QA Sun Microsystems Database Technology Group http://blogs.sun.com/austvik http://www.austvik.net/ Index: src/test/regress/GNUmakefile === RCS file: /projects/cvsroot/pgsql/src/test/regress/GNUmakefile,v retrieving revision 1.73 diff -c -r1.73 GNUmakefile *** src/test/regress/GNUmakefile 7 Apr 2008 14:15:58 - 1.73 --- src/test/regress/GNUmakefile 29 May 2008 12:17:18 - *** *** 122,127 --- 122,129 .PHONY: all-spi all-spi: $(MAKE) -C $(contribdir)/spi refint$(DLSUFFIX) autoinc$(DLSUFFIX) + cp $(contribdir)/spi/refint$(DLSUFFIX) . + cp $(contribdir)/spi/autoinc$(DLSUFFIX) . # Tablespace setup .PHONY: tablespace-setup Index: src/test/regress/input/create_function_1.source === RCS file: /projects/cvsroot/pgsql/src/test/regress/input/create_function_1.source,v retrieving revision 1.17 diff -c -r1.17 create_function_1.source *** src/test/regress/input/create_function_1.source 27 Feb 2006 16:09:50 - 1.17 --- src/test/regress/input/create_function_1.source 29 May 2008 12:17:18 - *** *** 24,40 CREATE FUNCTION check_primary_key () RETURNS trigger ! AS '@abs_builddir@/../../../contrib/spi/[EMAIL PROTECTED]@' LANGUAGE C; CREATE FUNCTION check_foreign_key () RETURNS trigger ! AS '@abs_builddir@/../../../contrib/spi/[EMAIL PROTECTED]@' LANGUAGE C; CREATE FUNCTION autoinc () RETURNS trigger ! AS '@abs_builddir@/../../../contrib/spi/[EMAIL PROTECTED]@' LANGUAGE C; CREATE FUNCTION funny_dup17 () --- 24,40 CREATE FUNCTION check_primary_key () RETURNS trigger ! AS '@abs_builddir@/[EMAIL PROTECTED]@' LANGUAGE C; CREATE FUNCTION check_foreign_key () RETURNS trigger ! AS '@abs_builddir@/[EMAIL PROTECTED]@' LANGUAGE C; CREATE FUNCTION autoinc () RETURNS trigger ! AS '@abs_builddir@/[EMAIL PROTECTED]@' LANGUAGE C; CREATE FUNCTION funny_dup17 () Index: src/test/regress/output/create_function_1.source === RCS file: /projects/cvsroot/pgsql/src/test/regress/output/create_function_1.source,v retrieving revision 1.30 diff -c -r1.30 create_function_1.source *** src/test/regress/output/create_function_1.source 18 Jun 2007 21:40:58 - 1.30 --- src/test/regress/output/create_function_1.source 29 May 2008 12:17:18 - *** *** 25,39 NOTICE: argument type city_budget is only a shell CREATE FUNCTION check_primary_key () RETURNS trigger ! AS '@abs_builddir@/../../../contrib/spi/[EMAIL PROTECTED]@' LANGUAGE C; CREATE FUNCTION check_foreign_key () RETURNS trigger ! AS '@abs_builddir@/../../../contrib/spi/[EMAIL PROTECTED]@' LANGUAGE C; CREATE FUNCTION autoinc () RETURNS trigger ! AS '@abs_builddir@/../../../contrib/spi/[EMAIL PROTECTED]@' LANGUAGE C; CREATE FUNCTION funny_dup17 () RETURNS trigger --- 25,39 NOTICE: argument type city_budget is only a shell CREATE FUNCTION check_primary_key () RETURNS trigger ! AS '@abs_builddir@/[EMAIL PROTECTED]@' LANGUAGE C; CREATE FUNCTION check_foreign_key () RETURNS trigger ! AS '@abs_builddir@/[EMAIL PROTECTED]@' LANGUAGE C; CREATE FUNCTION autoinc () RETURNS trigger ! AS '@abs_builddir@/[EMAIL PROTECTED]@' LANGUAGE C; CREATE FUNCTION funny_dup17 () RETURNS trigger begin:vcard fn;quoted-printable:J=C3=B8rgen Austvik n;quoted-printable:Austvik;J=C3=B8rgen org:Sun Microsystems;Database Group adr:;;Haakon VII gt. 7b;Trondheim;;NO-7485;Norway email;internet:[EMAIL PROTECTED] title:Senior Engineer tel;work:+47 73 84 21 10 tel;fax:+47 73 84 21 01 tel;cell:+47 901 97 886 note:http://www.austvik.net/ x-mozilla-html:FALSE url:http://blogs.sun.com/austvik/ version:2.1 end:vcard -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_regress: referencing shared objects from tests
Hi, we would like to be able to use and ship pg_regress and the PostgreSQL test suite independently of the PostgreSQL build environment, for testing and maybe even as a separate package to be build and shipped with the OS for others to test their setup. Does this sound like a sane and OK thing to do? I have a problem with one of the tests (create_function_1.source): -8888--- 20 CREATE FUNCTION int44out(city_budget) 21RETURNS cstring 22AS '@abs_builddir@/[EMAIL PROTECTED]@' 23LANGUAGE C STRICT; 24 25 CREATE FUNCTION check_primary_key () 26 RETURNS trigger 27 AS '@abs_builddir@/../../../contrib/spi/[EMAIL PROTECTED]@' 28 LANGUAGE C; ... 35 CREATE FUNCTION autoinc () 36 RETURNS trigger 37 AS '@abs_builddir@/../../../contrib/spi/[EMAIL PROTECTED]@' 38 LANGUAGE C; -8888--- (The ../../../contrib/spi-path does not exist outside of the build environment, so to be able to run the test you need to have source code, compilers, ...) I could work around this problem by copying the needed shared objects to @abs_builddir@ as part of make or make check, I could add a “–look-for-shared-objects-here” parameter to pg_regress, and you probably have other suggestions. Is this something we want to fix, and what would be the right way to do it? (I have no problem providing a patch.) -Jørgen -- Jørgen Austvik, Software Engineering - QA Sun Microsystems Database Group http://blogs.sun.com/austvik, http://www.autvik.net/ Sun Microsystems AS Haakon VII gt. 7b N-7485 Trondheim, Norway begin:vcard fn;quoted-printable:J=C3=B8rgen Austvik n;quoted-printable:Austvik;J=C3=B8rgen org:Sun Microsystems;Database Technology Group adr:;;Haakon VII gt. 7b;Trondheim;;NO-7485;Norway email;internet:[EMAIL PROTECTED] title:Senior Engineer tel;work:+47 73 84 21 10 tel;fax:+47 73 84 21 01 tel;cell:+47 901 97 886 x-mozilla-html:FALSE url:http://www.sun.com/ version:2.1 end:vcard -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_regress: dbname in PostgreSQL test suite
Hi.
pg_regress has a --dbname option (which actually take a list of database
names):
--dbname=DB use database DB (default \regression\)
... but the PostgreSQL regression test suite does not really support this:
[EMAIL PROTECTED]:regress] ggrep -R regression sql/* | grep -v
regression_ | grep -v :--
sql/prepare.sql:EXECUTE q2('regression');
sql/privileges.sql:\c regression
sql/temp.sql:\c regression
I suggest we replace @dbname@ with the first element in the dblist
linked list in convert_sourcefiles_in(). What do you think?
(I can provide a patch if you think it is an acceptable solution.)
-J
--
Jørgen Austvik, Software Engineering - QA
Sun Microsystems Database Group
http://blogs.sun.com/austvik/
http://www.austvik.net/
begin:vcard
fn;quoted-printable:J=C3=B8rgen Austvik
n;quoted-printable:Austvik;J=C3=B8rgen
org:Sun Microsystems;Database Group
adr:;;Haakon VII gt. 7b;Trondheim;;NO-7485;Norway
email;internet:[EMAIL PROTECTED]
title:Senior Engineer
tel;work:+47 73 84 21 10
tel;fax:+47 73 84 21 01
tel;cell:+47 901 97 886
note:http://www.austvik.net/
x-mozilla-html:FALSE
url:http://blogs.sun.com/austvik/
version:2.1
end:vcard
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Buildfarm member gypsy_moth seems not to like alignment patch
Tom Lane wrote:
This is unfortunate and surprising, since that patch was intended to
prevent compilers from making unsafe alignment assumptions, but it sure
looks like this compiler has instead added a new one. Could you poke
into it --- at least get a stack trace from the core dump?
Forgot some information about local variables:
(dbx) dump
toasttupDesc = 0xcf9538
chunk_size = 1996
t_values = ARRAY
toast_pointer = RECORD
chunk_seq = 1
rel = 0xcd8ff8
toastidx = 0xcf9858
toasttup = 0x8
toastrel = 0xcf9748
use_wal = '\001'
result = 0x1
data_p = 0xdbd354
use_fsm = '\001'
data_todo = 2286
mycid = 10U
__func__ = toast_save_datum
t_isnull = ARRAY
value = 14406480U
chunk_data = RECORD
(dbx) print toast_pointer
toast_pointer = {
va_rawsize= 11963
va_extsize= 2286
va_valueid= 10953U
va_toastrelid = 2838U
}
(dbx) print t_values
t_values = (10953U, 0, 4290673827U)
(dbx) print t_isnull
t_isnull =
(dbx) print chunk_data
chunk_data = {
hdr = {
vl_len_ =
vl_dat =
}
data =
}
-J
--
Jørgen Austvik, Software Engineering - QA
Sun Microsystems Database Technology Group
begin:vcard
fn;quoted-printable:J=C3=B8rgen Austvik
n;quoted-printable:Austvik;J=C3=B8rgen
org:Sun Microsystems;Database Technology Group
adr:;;Haakon VII gt. 7b;Trondheim;;NO-7485;Norway
email;internet:[EMAIL PROTECTED]
title:Senior Engineer
tel;work:+47 73 84 21 10
tel;fax:+47 73 84 21 01
tel;cell:+47 901 97 886
x-mozilla-html:FALSE
url:http://www.sun.com/
version:2.1
end:vcard
---(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: [HACKERS] Buildfarm member gypsy_moth seems not to like alignment patch
Tom Lane wrote: It looks like gypsy_moth has been failing like this: creating directory /export/home/tmp/pg-test/build-suncc/HEAD/pgsql.21325/src/test/regress/./tmp_check/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers/max_fsm_pages ... 32MB/204800 creating configuration files ... ok creating template1 database in /export/home/tmp/pg-test/build-suncc/HEAD/pgsql.21325/src/test/regress/./tmp_check/data/base/1 ... ok initializing pg_authid ... ok initializing dependencies ... ok creating system views ... Bus Error - core dumped child process exited with exit code 138 initdb: data directory /export/home/tmp/pg-test/build-suncc/HEAD/pgsql.21325/src/test/regress/./tmp_check/data not removed at user's request since I put in this patch: http://archives.postgresql.org/pgsql-committers/2008-02/msg00270.php This is unfortunate and surprising, since that patch was intended to prevent compilers from making unsafe alignment assumptions, but it sure looks like this compiler has instead added a new one. Could you poke into it --- at least get a stack trace from the core dump? Running initdb with debug: --888888-- $./initdb -D /export/home/tmp/test -d -n snip DEBUG: name: unnamed; blockState: STARTED; state: INPROGR, xid/subid/cid: 0/1/35, nestlvl: 1, children: DEBUG: commit transaction DEBUG: proc_exit(0) DEBUG: shmem_exit(0) DEBUG: exit(0) ok initializing pg_authid ... ok initializing dependencies ... ok creating system views ... Bus Error - core dumped child process exited with exit code 138 initdb: data directory /export/home/tmp/test not removed at user's request --888888-- Stack trace: --888888-- $ /opt/SUNWspro8/bin/dbx long_path/postgres core program terminated by signal BUS (invalid address alignment) Current function is toast_save_datum 1171 SET_VARSIZE(chunk_data, chunk_size + VARHDRSZ); (dbx) where =[1] toast_save_datum(rel = 0xcd8ff8, value = 14406480U, use_wal = \001', use_fsm = '\001'), line 1171 in tuptoaster.c [2] toast_insert_or_update(rel = 0xcd8ff8, newtup = 0xdba3e8, oldtup = (nil), use_wal = '\001', use_fsm = '\001'), line 700 in tuptoaster.c [3] heap_insert(relation = 0xcd8ff8, tup = 0xdba3e8, cid = 10U, use_wal = '\001', use_fsm = '\001'), line 1815 in heapam.c [4] simple_heap_insert(relation = 0xcd8ff8, tup = 0xdba3e8), line 1937 in heapam.c [5] InsertRule(rulname = 0xdaf730 _RETURN, evtype = 1, eventrel_oid = 10950U, evslot_index = -1, evinstead = '\001', event_qual = (nil), action = 0xdaf760, replace = '\0'), line 134 in rewriteDefine.c [6] DefineQueryRewrite(rulename = 0xdaf730 _RETURN, event_relid = 10950U, event_qual = (nil), event_type = CMD_SELECT, is_instead = '\001', replace = '\0', action = 0xdaf760), line 461 in rewriteDefine.c [7] DefineViewRules(viewOid = 10950U, viewParse = 0xdab070, replace = '\0'), line 275 in view.c [8] DefineView(stmt = 0xd3f920, queryString = 0xd9b888 /*\n * PostgreSQL System Views\n *\n * Copyright (c) 1996-2008, PostgreSQL Global Development Group\n *\n * $PostgreSQL: pgsql/src/backend/catalog/system_views.sql,v 1.47 2007/10/22 20:13:37 tgl Exp $\n */\n\nCREATE VIEW pg_roles AS \nSELECT \n rolname,\nrolsuper,\nrolinherit,\n rolcreaterole,\nrolcreatedb,\nrolcatupdate,\n rolcanlogin,\nrolconnlimit,\n''::text as rolpassword,\nrolvaliduntil,\nrolconfig,\noid\n FROM pg_aut ...), line 447 in view.c [9] ProcessUtility(parsetree = 0xd3f920, queryString = 0xd9b888 /*\n * PostgreSQL System Views\n *\n * Copyright (c) 1996-2008, PostgreSQL Global Development Group\n *\n * $PostgreSQL: pgsql/src/backend/catalog/system_views.sql,v 1.47 2007/10/22 20:13:37 tgl Exp $\n */\n\nCREATE VIEW pg_roles AS \nSELECT \n rolname,\nrolsuper,\nrolinherit,\n rolcreaterole,\nrolcreatedb,\nrolcatupdate,\n rolcanlogin,\nrolconnlimit,\n''::text as rolpassword,\nrolvaliduntil,\nrolconfig,\noid\n FROM pg_aut ..., params = (nil), isTopLevel = '\0', dest = 0xbb1534, completionTag = 0xffbef64c ), line 894 in utility.c [10] PortalRunUtility(portal = 0xd39e68, utilityStmt = 0xd3f920, isTopLevel = '\0', dest = 0xbb1534, completionTag = 0xffbef64c ), line 1178 in pquery.c [11] PortalRunMulti(portal = 0xd39e68, isTopLevel = '\0', dest = 0xbb1534, altdest = 0xbb1534, completionTag = 0xffbef64c ), line 1266 in pquery.c [12] PortalRun(portal = 0xd39e68, count = 2147483647, isTopLevel = '\0', dest = 0xbb1534, altdest = 0xbb1534, completionTag = 0xffbef64c ), line 814 in pquery.c [13] exec_simple_query(query_string = 0xd2fe38 /*\n * PostgreSQL System Views\n
[HACKERS] lo_export and lo_import: paths and servers
Hi, The PostgreSQL 8.3 documentation[1] says this about lo_export and lo_import paths and servers: Import: Note that the file is read by the client interface library, not by the server; so it must exist in the client file system and be readable by the client application. Export: Note that the file is written by the client interface library, not by the server. The way I read this is that both for lo_import and lo_export, the files should be placed (and be readable) on the local file system for the client. However, the behaviour I see when I run pg_regress and the large in client/server mode over two different hosts, is that pg_export works against the server file system (the file is written there), while pg_import work against the client file system (the file is not there when it tries to read it), leading to the result below. Problem between keyboard and chair, in doc, libpq, psql or elsewhere? -8--8--8--8--8 SELECT lo_export(loid, '/export/home/tmp/jagtmp/ja155679pgRegress/install/share/regress/results/lotest.txt') FROM lotest_stash_values; lo_export --- 1 (1 row) \lo_import '/export/home/tmp/jagtmp/ja155679pgRegress/install/share/regress/results/lotest.txt' could not open file /export/home/tmp/jagtmp/ja155679pgRegress/install/share/regress/results/lotest.txt: No such file or directory \set newloid :LASTOID -- just make sure \lo_export does not barf \lo_export :newloid '/export/home/tmp/jagtmp/ja155679pgRegress/install/share/regress/results/lotest2.txt' ERROR: large object 0 does not exist -8--8--8--8--8 [1] http://www.postgresql.org/docs/8.3/static/lo-interfaces.html -J -- Jørgen Austvik, Software Engineering - QA Sun Microsystems Database Technology Group begin:vcard fn;quoted-printable:J=C3=B8rgen Austvik n;quoted-printable:Austvik;J=C3=B8rgen org:Sun Microsystems;Database Technology Group adr:;;Haakon VIII gt. 7b;Trondheim;;NO-7485;Norway email;internet:[EMAIL PROTECTED] title:Senior Engineer tel;work:+47 73 84 21 10 tel;fax:+47 73 84 21 01 tel;cell:+47 901 97 886 x-mozilla-html:FALSE url:http://www.sun.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] lo_export and lo_import: paths and servers
Jorgen Austvik - Sun Norway wrote: Problem between keyboard and chair, in doc, libpq, psql or elsewhere? Sorry, the psql documentation is clear on this: \lo_export Note that this is subtly different from the server function lo_export, which acts with the permissions of the user that the database server runs as and on the server's file system. \lo_import Note that this command is subtly different from the server-side lo_import because it acts as the local user on the local file system, rather than the server's user and file system. -J -- Jørgen Austvik, Software Engineering - QA Sun Microsystems Database Technology Group begin:vcard fn;quoted-printable:J=C3=B8rgen Austvik n;quoted-printable:Austvik;J=C3=B8rgen org:Sun Microsystems;Database Technology Group adr:;;Haakon VIII gt. 7b;Trondheim;;NO-7485;Norway email;internet:[EMAIL PROTECTED] title:Senior Engineer tel;work:+47 73 84 21 10 tel;fax:+47 73 84 21 01 tel;cell:+47 901 97 886 x-mozilla-html:FALSE url:http://www.sun.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] How to determine if psql returns ZERO to the shell and finished successfully?
Tommy wrote: How exactly can I check to see if psql returns ZERO to the shell? What do I test for? If(Psql.exe)? or is there a variable I can check to see if it has been set? If you are running Delphi on Windows (the MsgBox makes me guess so), take a look here: http://delphi.about.com/od/windowsshellapi/a/executeprogram.htm -J -- Jørgen Austvik, Software Engineering - QA Database Technology Group Sun Microsystems AS Haakon VII gt. 7b N-7485 Trondheim, Norway Phone +47 73 84 21 10 Fax+47 73 84 21 01 Mobile +47 90 19 78 86 begin:vcard fn;quoted-printable:J=C3=B8rgen Austvik n;quoted-printable:Austvik;J=C3=B8rgen org:Sun Microsystems;Database Technology Group adr:;;Haakon VIII gt. 7b;Trondheim;;NO-7485;Norway email;internet:[EMAIL PROTECTED] title:Senior Engineer tel;work:+47 73 84 21 10 tel;fax:+47 73 84 21 01 tel;cell:+47 901 97 886 x-mozilla-html:FALSE url:http://www.sun.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
