Re: [HACKERS] locale support
> > I know this is not PostgreSQL's fault but the broken locale data on > > certain platforms. The problem makes it impossible to use PostgreSQL > > RPMs in Japan. > > > I'm looking for solutions/workarounds for this problem. > > Build a set of RPMs without locale support? >Run it with LC_ALL="C". Both of them seem not ideal solutions for RPM. It would be nice if we could distribute single binary and start up file in RPM. -- Tatsuo Ishii
Re: [HACKERS] Recovery of PGSQL after system crash failing!!!
Ryan Kirkpatrick <[EMAIL PROTECTED]> writes: > #2 0x20dc71 in abort () from /lib/libc.so.6 > #3 0x8080495 in XLogFileOpen () Hm. Evidently it's failing to open the xlog file, but the code is set up in such a way that it dies before telling you why :-( Take a look at XLogFileOpen in src/backend/access/transam/xlog.c and tweak the code to tell you the path and errno it's failing on before it abort()s. regards, tom lane
Re: [HACKERS] Recovery of PGSQL after system crash failing!!!
On Mon, 12 Feb 2001, Ryan Kirkpatrick wrote: > One other wrench to thrown into the works... The kernel on this > machine is 2.2.18 with the patches listed at www.linuxraid.org applied. I > have a feeling that the linux-security patches mentioned on that page may > be giving pgsql heartburn on recovery. I am going to recompile the kernel > w/o them enabled and see if anything different results, and will post my > results. Did as above, disabling all security options in the kernel, recompiling, and rebooting. Postgres behaves exactly the same as before. :( --- | "For to me to live is Christ, and to die is gain."| |--- Philippians 1:21 (KJV) | --- | Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ | ---
Re: [HACKERS] Recovery of PGSQL after system crash failing!!!
On Sun, 11 Feb 2001, Vadim Mikheev wrote: > Please try to restart with option wal_debug = 1 so postmaster log > will be more informative and send this log me. I enabled 'wal_debug=1' via both the -c command line option and (seperately) via ./data/postgresql.conf, as well as setting wal_debug=16 in ./data/postgresql.conf and I got no addition postmaster log information than in my last email. :( Also set my coredump limit to unlimited (ulimit -c unlimited) and started postmaster up. I got a core file, and here is what gdb has to say about it: GNU gdb 19990928 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (no debugging symbols found)... Core was generated by `postmaster -d 5 -D /usr/local/pgsql/data/'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done. Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done. Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Reading symbols from /lib/libreadline.so.4...(no debugging symbols found)...done. Reading symbols from /lib/libncurses.so.5...(no debugging symbols found)...done. Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. #0 0x20c931 in kill () from /lib/libc.so.6 (gdb) bt #0 0x20c931 in kill () from /lib/libc.so.6 #1 0x20c618 in raise () from /lib/libc.so.6 #2 0x20dc71 in abort () from /lib/libc.so.6 #3 0x8080495 in XLogFileOpen () #4 0x8080b52 in ReadRecord () #5 0x8081f66 in StartupXLOG () #6 0x80853ea in BootstrapMain () #7 0x80ee1e7 in SSDataBase () #8 0x80ec766 in PostmasterMain () #9 0x80cd194 in main () #10 0x206a42 in __libc_start_main () from /lib/libc.so.6 Also, since it appears it died in XLogFileOpen(), here is what the directory structure looks like for xlog related files: drwx--S---5 postgres postgres 4096 Feb 12 20:51 data drwx--S---2 postgres postgres 4096 Feb 11 04:12 data/pg_xlog -rw---1 postgres postgres 16777216 Feb 11 04:12 data/pg_xlog/0030 The file listed in data/pg_xlog is the only file in this directory. Does not look like a lot of help to me, but here it is also. One other wrench to thrown into the works... The kernel on this machine is 2.2.18 with the patches listed at www.linuxraid.org applied. I have a feeling that the linux-security patches mentioned on that page may be giving pgsql heartburn on recovery. I am going to recompile the kernel w/o them enabled and see if anything different results, and will post my results. > > data; initdb'? A quick response would be greatly appreciated. Thanks. > > Please archieve PG' data dir - it probably will be useful to find bug. Archived. It is a bit over 11MB, and I can put it on my web server if some one wants to look at it (10 minute download with a 192kbit or faster link). Though I would like to limit its distribution as it does have relatively sensitive company data buried in it (custom lists and the like). Though there is nothing I need to retrieve from it... This database is from the web site that is updated every night from the internal databases. For the time being I have fallen back to 7.0.3 for production use. Thank you for all of your help. TTYL. --- | "For to me to live is Christ, and to die is gain."| |--- Philippians 1:21 (KJV) | --- | Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ | ---
Re: [HACKERS] locale support
Tatsuo Ishii <[EMAIL PROTECTED]> writes: > I know this is not PostgreSQL's fault but the broken locale data on > certain platforms. The problem makes it impossible to use PostgreSQL > RPMs in Japan. > I'm looking for solutions/workarounds for this problem. Build a set of RPMs without locale support? regards, tom lane
Re: [HACKERS] locale support
On Mon, Feb 12, 2001 at 09:59:37PM -0500, Tom Lane wrote: > Tatsuo Ishii <[EMAIL PROTECTED]> writes: > > I know this is not PostgreSQL's fault but the broken locale data on > > certain platforms. The problem makes it impossible to use PostgreSQL > > RPMs in Japan. > > > I'm looking for solutions/workarounds for this problem. > > Build a set of RPMs without locale support? Run it with LC_ALL="C". Nathan Myers [EMAIL PROTECTED]
[HACKERS] locale support
There is a serious problem with the PostgreSQL locale support on certain platforms and certain locale combo. That is: simply ordering, indexes etc. are broken because strcoll() does not work. Example combo includes: RedHat 6.2J(Japanese localized version) + ja_JP.eucJP locale. Here is a test program that expose the problem. #include #include main() { static char *s1 = "a Japanese string"; static char *s2 = "another Japanese string"; setlocale(LC_ALL,""); printf("%d\n",strcoll(s1,s2)); printf("%d\n",strcoll(s2,s1)); } This program prints 0s, that means strcoll() regards that those differnt Japanese strings are same! I know this is not PostgreSQL's fault but the broken locale data on certain platforms. The problem makes it impossible to use PostgreSQL RPMs in Japan. I'm looking for solutions/workarounds for this problem. Maybe we should disable locale support at runntime if strcoll() does not work? Comments? -- Tatsuo Ishii
Re: [HACKERS] New setval() call
At 18:34 10/02/01 -0500, Bruce Momjian wrote: > >Can you give me a few lines to put in sequence.c? There isn't even >anything in there! > I've now put comments on setval, setval_is_called and do_setval. 3 for the price of one. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] pg_dump output
At 18:49 12/02/01 +0100, Kovacs Zoltan wrote: >In 7.0.2 I got > >INSERT INTO foo (field) VALUES ('Hello,\012world!'); > >In 7.1beta4 I get > >INSERT INTO foo (field) VALUES ('Hello, >world!'); > I have modified formatLiteralString to accept an arg that tells it how to handle LF & TAB. Now, it will encode *everything* except in comments and procedure bodies. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
[HACKERS] Redundant UNIQUE specs (was Re: [GENERAL] bad error message)
"Martin A. Marques" <[EMAIL PROTECTED]> writes: > test=# CREATE TABLE dedicacion ( > test(#id_dedi SERIAL UNIQUE, > test(#nombre_dedi CHAR(10) UNIQUE > test(# ); > NOTICE: CREATE TABLE will create implicit sequence 'dedicacion_id_dedi_seq' > for SERIAL column 'dedicacion.id_dedi' > NOTICE: CREATE TABLE/UNIQUE will create implicit index > 'dedicacion_id_dedi_key' for table 'dedicacion' > NOTICE: CREATE TABLE/UNIQUE will create implicit index > 'dedicacion_id_dedi_key' for table 'dedicacion' > NOTICE: CREATE TABLE/UNIQUE will create implicit index > 'dedicacion_nombre_dedi_key' for table 'dedicacion' > ERROR: Cannot create index: 'dedicacion_id_dedi_key' already exists Hm. There is code in the parser to discard duplicate UNIQUE specifications when a PRIMARY KEY is present. Shouldn't it just do so in all cases, PRIMARY KEY or no? regards, tom lane
Re: [HACKERS] pg_dump output
At 22:25 12/02/01 +0100, Kovacs Zoltan wrote: >By the way, I get each sequence twice in pg_dump output... In psql: > >CREATE TABLE x (y SERIAL); > >Then running pg_dump with switches -xacnOD, I get: > >-- >-- Selected TOC Entries: >-- >DROP SEQUENCE x_y_seq; >DROP SEQUENCE x_y_seq; Doesn't happen here - does anybody else see this? Can you confirm it happens on a freshly created database? If so, can you try: pg_dump blah -Fc -v > z.bck and send both the output and z.bck direct to me? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
[HACKERS] RE: [ODBC] RE: [PATCHES] Fix for ODBC close
> -Original Message- > From: Bruce Momjian [mailto:[EMAIL PROTECTED]] > Sent: 11 February 2001 06:31 > To: PostgreSQL-development > Cc: Dave Page; PostgreSQL odbc list; PostgreSQL-patches > Subject: Re: [ODBC] RE: [PATCHES] Fix for ODBC close > > > OK, I have a pretty good guess about the cause of the ODBC shutdown > failure message in the server logs. Sending 'X' is still causing the > error message. > > The error you are seeing is from the backend libpq code, the area that > communicates with clients. > > So, let's assume the problem is not the platform, but the > client code. > Libpq properly shuts connections without triggering that > message. ODBC > does trigger the message. > > libpq closes connections with: > > (void) pqPuts("X", conn); > (void) pqFlush(conn); > > while ODBC closes with: > > SOCK_put_char(self, 'X'); > SOCK_flush_output(self); > > They then close() the socket. > > It seems the difference is in the flushing. libpq has elaborate flush > code: > > while (len > 0) > { > sent = send(conn->sock, ptr, len, 0); > len -= sent; > > if (pqWait(FALSE, TRUE, conn)) > } > > and pqWait does: > > if (select(conn->sock + 1, &input_mask, > &output_mask, (fd_set *) NULL, > > > For flush, ODBC does a simple: > > written = send(self->socket, (char *) self->buffer_out, > self->buffer_filled_out, 0); > > > It seems we may need to add flush code similar to libpq in ODBC. > > At a minimum, we have to put the send() in a loop and keep going until > there are no more bytes to send. Not sure the select() is required. > > Comments? > > After I receive comments, I will prepare a patch people can test. Sounds reasonable though I must admit this isn't exactly my area of expertise! I'll certainly test any patches though and make a .dll available for others to try. Regards, Dave.
Re: [HACKERS] pg_dump output
By the way, I get each sequence twice in pg_dump output... In psql: CREATE TABLE x (y SERIAL); Then running pg_dump with switches -xacnOD, I get: -- -- Selected TOC Entries: -- DROP SEQUENCE x_y_seq; DROP SEQUENCE x_y_seq; -- -- TOC Entry ID 1 (OID 2625010) -- -- Name: x_y_seq Type: SEQUENCE Owner: postgres -- CREATE SEQUENCE x_y_seq start 1 increment 1 maxvalue 2147483647 minvalue 1 cache 1 ; -- -- TOC Entry ID 3 (OID 2625010) -- -- Name: x_y_seq Type: SEQUENCE Owner: postgres -- CREATE SEQUENCE x_y_seq start 1 increment 1 maxvalue 2147483647 minvalue 1 cache 1 ; -- -- Data for TOC Entry ID 5 (OID 2625029) TABLE DATA x -- \connect - postgres -- Disable triggers UPDATE "pg_class" SET "reltriggers" = 0 WHERE "relname" ~* 'x'; -- Enable triggers CREATE TEMP TABLE "tr" ("tmp_relname" name, "tmp_reltriggers" smallint); INSERT INTO "tr" SELECT C."relname", count(T."oid") FROM "pg_class" C, "pg_trigger" T WHERE C."oid" = T."tgrelid" AND C."relname" ~* 'x' GROUP BY 1; UPDATE "pg_class" SET "reltriggers" = TMP."tmp_reltriggers" FROM "tr" TMP WHERE "pg_class"."relname" = TMP."tmp_relname"; DROP TABLE "tr"; COMMIT TRANSACTION; -- -- TOC Entry ID 2 (OID 2625010) -- -- Name: x_y_seq Type: SEQUENCE SET Owner: -- SELECT setval ('x_y_seq', 1, 'f'); -- -- TOC Entry ID 4 (OID 2625010) -- -- Name: x_y_seq Type: SEQUENCE SET Owner: -- SELECT setval ('x_y_seq', 1, 'f'); - Is this correct? Zoltan -- Kov\'acs, Zolt\'an [EMAIL PROTECTED] http://www.math.u-szeged.hu/~kovzol ftp://pc10.radnoti-szeged.sulinet.hu/home/kovacsz
Re: [HACKERS] pg_dump output
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane writes: >> Peter Eisentraut <[EMAIL PROTECTED]> writes: > Btw., if I select the default COPY output, pg_dump seems to drop > non-printable characters like '\001'. >> >> You sure? They're there in my output. COPY doesn't turn them into >> escape sequences, if that's what you were expecting. > If I do > INSERT INTO test VALUES ('foo\001bar'); > then pg_dump writes > COPY "test" FROM stdin; > foobar > \. What I get is 'foo^Abar'. What are you using to inspect the file? regards, tom lane
Re: [HACKERS] pg_dump output
Tom Lane writes: > What are you using to inspect the file? Ugh... :-/ -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] pg_dump output
Tom Lane writes: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Btw., if I select the default COPY output, pg_dump seems to drop > > non-printable characters like '\001'. > > You sure? They're there in my output. COPY doesn't turn them into > escape sequences, if that's what you were expecting. If I do INSERT INTO test VALUES ('foo\001bar'); then pg_dump writes COPY "test" FROM stdin; foobar \. This is incorrect. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] RE: [PATCHES] Fix for ODBC close
> -Original Message- > From: Bruce Momjian [mailto:[EMAIL PROTECTED]] > Sent: 10 February 2001 05:46 > To: PostgreSQL odbc list; PostgreSQL-patches > Cc: PostgreSQL-development > Subject: [PATCHES] Fix for ODBC close > > > I have applied the following patch to properly exit ODBC. I just compiled from the current cvs under win32 and I still get 'pq_recvbuf: unexpected EOF on client connection' when exiting apps using the ODBC driver. I have tested with pgAdmin which uses ADO (ActiveX Data Objects) and certainly closes the ADO connection object on exit, as well as a simple test app using DAO (Data Access Objects). I did have a go at fixing this myself when Bruce first mentioned it, and had exactly the same results with similar code :-( Regards, Dave.
[HACKERS] Re: [PATCHES] Fix for ODBC close
[EMAIL PROTECTED] wrote: > I have applied the following patch to properly exit ODBC. I also > patched the ODBC makefile so it links under BSD/OS. The -Bsymbolic > under BSD/OS is very harsh under BSD/OS, requiring all symbols even in > libc and crt1.o to be resolved before creating the shared library. > > My 'ld' manual says: > >-Bsymbolic > When creating a shared library, bind references to > global symbols to the definition within the shared > library, if any. Normally, it is possible for a > program linked against a shared library to override > the definition within the shared library. This op- > tion is only meaningful on ELF platforms which sup- > port shared libraries. Hmm, removing that may break it when running under a driver manager though... I will check of FreeBSD, it certainly will on Linux ELF. -- Nick Gorham When I die, I want to go like my grandfather did, gently while sleeping, and not like his passangers, screaming in a panic, looking for the inflatable raft. -- Seen on ./
Re: [HACKERS] pg_dump output
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Btw., if I select the default COPY output, pg_dump seems to drop > non-printable characters like '\001'. You sure? They're there in my output. COPY doesn't turn them into escape sequences, if that's what you were expecting. regards, tom lane
Re: [HACKERS] pg_dump output
On Mon, 12 Feb 2001, Peter Eisentraut wrote: > Kovacs Zoltan writes: > > > In 7.0.2 I got > > INSERT INTO foo (field) VALUES ('Hello,\012world!'); > > > In 7.1beta4 I get > > INSERT INTO foo (field) VALUES ('Hello, > > world!'); > > > Is it possible to add a switch to pg_dump to make it possible getting the > > old output. Where can I balance it in the source if I'd like to change the > > behaviour? > > I kind of agree that the old output should be preferred. Otherwise we > might be entering a whole new world of CR/LF sort of problems. > > Btw., if I select the default COPY output, pg_dump seems to drop > non-printable characters like '\001'. OK, I found it. In pg_dump.c, function formatStringLiteral(), the line containing '\n' and '\t' should be deleted (or check whether a switch is on or not). Zoltan -- Kov\'acs, Zolt\'an [EMAIL PROTECTED] http://www.math.u-szeged.hu/~kovzol ftp://pc10.radnoti-szeged.sulinet.hu/home/kovacsz
Re: [HACKERS] pg_dump output
Kovacs Zoltan writes: > In 7.0.2 I got > INSERT INTO foo (field) VALUES ('Hello,\012world!'); > In 7.1beta4 I get > INSERT INTO foo (field) VALUES ('Hello, > world!'); > Is it possible to add a switch to pg_dump to make it possible getting the > old output. Where can I balance it in the source if I'd like to change the > behaviour? I kind of agree that the old output should be preferred. Otherwise we might be entering a whole new world of CR/LF sort of problems. Btw., if I select the default COPY output, pg_dump seems to drop non-printable characters like '\001'. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] RE: [ADMIN] SOS !!: Porstgress forgot all ! Help !
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes: >> before this manipulmation, pg_log = 1.073.741.824 > O, your system reached max transaction ID -:( That's two reports now of people who have managed to wrap around the XID counter. It doesn't seem that hard to do in a heavily used database. Does anyone want to take more seriously the stopgap solution I proposed for this problem (pghackers archives around 3-Nov-00)? I believe you shot it down that time, but I don't think that ignoring the problem for another release cycle is a better answer. regards, tom lane
[HACKERS] Re: Table name scope (was Re: [BUGS] Outer joins aren't working with views)
So there are two issues here which I hope to clarify: scoping on joins, and NATURAL and USING join column sets. I've been looking some more at this business, and I have found one of the reasons that I was confused. The SQL92 spec says (6.3 syntax rule 2) 2) Case: a) If a TR is contained in a FC with no intervening , then the scope clause SC of TR is the or innermost that contains FC. The scope clause of the exposed or exposed of TR is the , , , and of SC, together with the of all s contained in SC that contains TR. b) Otherwise, the scope clause SC of TR is the outermost that contains TR with no intervening . The scope of the exposed or exposed of TR is the of SC and of all s contained in SC that contain TR. I mistakenly read this with the assumption that means a sub-SELECT. It does mean that, but it also means a , *if and only if* that joined table is labeled with a . The relevant productions are: ::= [ [ AS ] [] ] | [ AS ] [] | ::= ::= ::= ::= | So "() AS foo" has a but "" doesn't. AFAICT, this means that table references defined within the join are invisible outside "() AS foo", but they are visible outside a plain "". This is more than a tad bizarre ... but it explains the examples you quoted from Date and Darwen. However, as long as a table reference is visible, I think that the set of qualified column names available from it should not depend on whether it came from inside a JOIN expression or not. Comments? regards, tom lane
[HACKERS] RE: [ADMIN] SOS !!: Porstgress forgot all ! Help !
> before this manipulmation, pg_log = 1.073.741.824 O, your system reached max transaction ID -:( > and xmin = 4982339 And now all tuples with xmin > ~500 are invisible. One way to restore data could be hack vacuum to update xmin of all valid tuples to 512, vacuum all tables, dump data, initdb new fresh database etc -:(( Vadim
[HACKERS] pg_dump output
Due to the urgency, I resend my mail about pg_dump output: In 7.0.2 I got INSERT INTO foo (field) VALUES ('Hello,\012world!'); In 7.1beta4 I get INSERT INTO foo (field) VALUES ('Hello, world!'); I am using these switches: -a, -c, -n, -d or -D. Is it possible to add a switch to pg_dump to make it possible getting the old output. Where can I balance it in the source if I'd like to change the behaviour? TIA, Zoltan -- Kov\'acs, Zolt\'an [EMAIL PROTECTED] http://www.math.u-szeged.hu/~kovzol ftp://pc10.radnoti-szeged.sulinet.hu/home/kovacsz
Re: [HACKERS] PL/PgSQL GET DIAGNOSTICS command
> On Fri, Feb 09, 2001 at 12:04:08PM -0500, Bruce Momjian wrote: > > I see the new PL/PgSQL command: > > > > GET DIAGNOSTICS > > > > This seems like a poorly-worded command to me. It is meant to return > > the number of rows affected by a previous query, right? > > Among other things, eventually. You get to blame the SQL standards > committee, again: > > > wallace$ grep 'GET DIAGNOSTICS' sql1992.txt > GET DIAGNOSTICS > That is unbelievable! (But true.) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] RE: [ADMIN] SOS !!: Porstgress forgot all ! Help !
> Then if I reindex my DB I have : > > NOTICE: --Relation astro-- > NOTICE: Pages 204: Changed 0, reaped 0, Empty 0, New 0; Tup > 4878: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 324, MaxLen 324; > Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.04s/0.18u sec. > NOTICE: Index astro_pkey: Pages 25; Tuples 4878. CPU 0.01s/0.01u sec. > > If I do : > select * from astro; > > I have : > ... > (0 rows) Well, it may be caused by corrupted next_xid in pg_variable. Could you CREATE TABLE foo (bar int); select xmin from pg_class where relname = 'foo'; and say what is exact size of pg_log file? Vadim
Re: [HACKERS] PL/PgSQL GET DIAGNOSTICS command
Bruce Momjian writes: > I see the new PL/PgSQL command: > > GET DIAGNOSTICS > > This seems like a poorly-worded command to me. It is meant to return > the number of rows affected by a previous query, right? That's how SQL wants it. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] PL/PgSQL GET DIAGNOSTICS command
On Fri, Feb 09, 2001 at 12:04:08PM -0500, Bruce Momjian wrote: > I see the new PL/PgSQL command: > > GET DIAGNOSTICS > > This seems like a poorly-worded command to me. It is meant to return > the number of rows affected by a previous query, right? Among other things, eventually. You get to blame the SQL standards committee, again: wallace$ grep 'GET DIAGNOSTICS' sql1992.txt GET DIAGNOSTICS Ross
[HACKERS] PL/PgSQL GET DIAGNOSTICS command
I see the new PL/PgSQL command: GET DIAGNOSTICS This seems like a poorly-worded command to me. It is meant to return the number of rows affected by a previous query, right? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Solaris 5.6 install problem
Amit Sharma writes: > libpq/SUBSYS.o(.text+0x5038): undefined reference to `__inet_ntoa' > I was getting the same trouble with installing Apache WebServer in my > account and had to go and modify the "makefiles" to include > -lbind option in them. Do i have to do the same thing here as well, i > tried doing that though and it didn't work. I think you need to add -lresolv. Edit src/Makefile.global, the line LIBS=... -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] Re: [INTERFACES] pgAccess fails to launch on HPUX
"Ross J. Reedstrom" wrote: > > Does anyone object if I modify pgaccess so that it always specifies the > > full path to the library? That seems like it'd be a good idea even on > > OSes without this quirk, because it'd ensure getting the matching > > version of libpgtcl and libpq even if your SHLIB_PATH/LD_LIBRARY_PATH > > points to some other version. > > Sounds like a good idea, to me. Getting the wrong library loaded leads to > non-obvious error messages, as well. > > Ross Yes. The full path to libpgtcl might be specified directly in pgaccess. But libpq library need to be found automatically because it isn't in a "load" explicit command. Constantin Teodorescu
[HACKERS] SPI_exec - Trying to access SPI_tuptable - error of 'dereferencing pointer to incomplete type'
Hi all, I'm starting to program with the SPI interface with PG 7.0.3. I can get everything to work up until I use SPI_exec (successfully) using a query like 'SELECT foobar, baz1 from test1'. The return code from SPI_exec indicates SPI_OK_SELECT and the variable SPI_processed is 2 (meaning there are two 'results' available from the select); The trouble is that when I try and access the global variable SPI_tuptable, I get the error 'dereferencing pointer to incomplete type'. The offending line in question in my source code is : elog(NOTICE, "\nSPI_tuptable->alloced = %u\n\0", SPI_tuptable->alloced); The feeling I get is something is incorrect in the header files I'm using. So far I've been able to point to the installed include files (/opt/postgresql/include) and have everything work. Now that I'm getting errors I've decided to try pointing to the source code (/install/postgresql-7.0.3/src/include and /install/postgresql-7.0.3/src/backend) in the hope the include files are more complete. This is where I get the error "dereferencing pointer to incomplete type" with the above line of code. The exact command I'm using to compile is "gcc -fpic -shared -I/install/postgresql-7.0.3/src/include/ -I/install/postgresql-7.0.3/src/backend -L/install/postgresql-7.0.3/src/lib -o booking_sp_id.so booking_sp_id.c" Can someone please give me some pointers as to what I'm doing wrong? Regards and best wishes, Justin Clift Database Administrator
Re: [HACKERS] Plan for straightening out the include-file mess
Great! :) It might also clean up something that I've been fighting against for awhile: when I include files needed for SPI, it drags also a lot of other garbage in, which conflicts with other things (namely, trying to get a file to simultaneously include SPI and perl headers is impossible). I realise it might be a lot of pain to clean up, but, you may consider having a separate top-level include for SPI, which would not define (by default) things like DEBUG, USE_LOCALE, union semun, etc. IMHO, it should really include only definitions of relevant data structures which interface with SPI code... I realize that complete split for SPI/module from "core backend" might be very hard, so a thing to consider would be to have (like linux kernel code has) #define IN_CORE (you are welcome to come up with better name), and include "core backend"-specific things conditionally on that being defined. -alex On Thu, 8 Feb 2001, Tom Lane wrote: > I have been looking at making a split between client-side and server-side > include files as we discussed earlier this week (pghackers thread > "Include files for SPI are not installed", if you missed it). It turns > out that the major issue here is not just divvying up the files; the > problem is that we have never had a clear concept of such a division > before, and so the core include files like postgres.h, c.h, config.h > contain a rather unholy mixture of things that are definitely > backend-only with things that are relevant to both clients and backends. > I think we need to start by clarifying the roles of these include files > and moving their contents around as necessary. > > Currently, almost every .c in the distribution starts out by including > postgres.h, which in turn includes these other files: > > postgres.h > postgres_ext.h > c.h > config.h > os.h > utils/elog.h > utils/palloc.h > > Now elog.h and palloc.h are server-only facilities and certainly don't > belong in a client file's include set. I think what we want to do is > decree that postgres.h is the primary include file for backend .c files > only, and that frontend .c files should include something else. > > postgres_ext.h would be a candidate to be that something else, except > that it's included by libpq-fe.h, so anything we add to postgres_ext.h > represents namespace pollution for libpq clients. I think we should be > very wary about adding a lot of stuff to postgres_ext.h. This suggests > that we'd best create a new primary include file for client-side .c files, > say "postgres_fe.h" or "postgres_client.h". (Anyone have a better naming > idea? Does the old 14-character limit still pose a problem anywhere?) > > That would leave us with include trees like this: > > backend .c file: > postgres.h > postgres_ext.h > c.h > config.h > os.h > utils/elog.h > utils/palloc.h > > frontend .c file: > postgres_fe.h > postgres_ext.h > c.h > config.h > os.h > > where the include files have these roles: > > postgres_ext.h: definitions needed in frontend, backend, *and* by clients; > by design an extremely small file > > postgres.h: backend-wide definitions > > postgres_fe.h: definitions common to all client-side interface libraries > > c.h: basic typedefs and macros needed by both frontend and backend, but > not intended to be exported to clients of frontend libraries > > config.h: configuration definitions, not intended to be client-visible > > os.h: platform-specific configuration hacks, not intended to be > client-visible (this comes from one of the src/include/port files) > > config.h and os.h don't need to change, I think, but I'll go through the > definitions in the other four files and make sure everything is classified > reasonably. > > It's possible that postgres_fe.h will end up containing nothing except > the inclusions of postgres_ext.h and c.h, in which case we wouldn't really > need to invent that file, but I'm still inclined to do so. I think it's > good practice to have a single include file that's the basic "must haves" > for all client-side code. > > > Now, since the intent is that the basic install provide headers needed > for client-side programming, we'd want to add postgres_fe.h to the > installed header set. But the following files can be removed from the > basic install: > > access/attnum.h > commands/trigger.h > executor/spi.h > fmgr.h > postgres.h > utils/elog.h > utils/geo_decls.h > utils/palloc.h > > We might also remove utils/fmgroids.h. I'm uncertain about this one. > The function OID macros it contains are potentially useful to clients, > but do we really want people hard-wiring function OIDs on the client > side? I doubt it. > > There are two or three other include files, such
[HACKERS] Solaris 5.6 install problem
Hi !! I am trying to install Postgresql-7.0.3 on the solaris 5.6 machine and i am trying to configure it as a user and not as a root because i don't have root access as it is my computer science departmental machine. when i run a make it gives the following error: gmake[3]: Leaving directory `/cis/mira/projects/temp/postgresql-7.0.3/src/backen d/utils/time' sh Gen_fmgrtab.sh ../../include/catalog/pg_proc.h /usr/local/bin/gcc -I../../include -I../../backend-I..-c fmgrtab.c -o fm grtab.o ld -r -o SUBSYS.o fmgrtab.o adt/SUBSYS.o cache/SUBSYS.o error/SUBSYS.o fmgr/SUBS YS.o hash/SUBSYS.o init/SUBSYS.o misc/SUBSYS.o mmgr/SUBSYS.o sort/SUBSYS.o time/ SUBSYS.o gmake[2]: Leaving directory `/cis/mira/projects/temp/postgresql-7.0.3/src/backen d/utils' /usr/local/bin/gcc -I../include -I../backend-o postgres access/SUBSYS.o boot strap/SUBSYS.o catalog/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o parser/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS .o tcop/SUBSYS.o utils/SUBSYS.o ../utils/version.o -lgen -lcrypt -lnsl -lsocket -ldl -lm -lreadline -ltermcap -lncurses libpq/SUBSYS.o: In function `be_recvauth': libpq/SUBSYS.o(.text+0x5038): undefined reference to `__inet_ntoa' libpq/SUBSYS.o: In function `process_hba_record': libpq/SUBSYS.o(.text+0x60b0): undefined reference to `__inet_aton' libpq/SUBSYS.o(.text+0x6114): undefined reference to `__inet_aton' libpq/SUBSYS.o: In function `ident': libpq/SUBSYS.o(.text+0x6cbc): undefined reference to `__inet_ntoa' libpq/SUBSYS.o(.text+0x6dd0): undefined reference to `__inet_ntoa' libpq/SUBSYS.o(.text+0x6ea0): undefined reference to `__inet_ntoa' tcop/SUBSYS.o: In function `PostgresMain': tcop/SUBSYS.o(.text+0x30e8): undefined reference to `__inet_ntoa' gmake[1]: *** [postgres] Error 1 gmake[1]: Leaving directory `/cis/mira/projects/temp/postgresql-7.0.3/src/backen d' gmake: *** [all] Error 2 Please if someone can help me out. I was getting the same trouble with installing Apache WebServer in my account and had to go and modify the "makefiles" to include -lbind option in them. Do i have to do the same thing here as well, i tried doing that though and it didn't work. Regards, Amit --- "Let Noble thoughts come to us from all directions." -Rig Veda --- Home: Office: Amit Sharma, Amit Sharma, 1119,Kearney st., Graduate Assistant, Appt # 8, Dept. Of Mathematics, Manhattan, Kansas State Univ., Kansas,66502. Kansas,66502. Ph. No. 1-785-5373052 Ph. No.1-785-5320561.
Re: [HACKERS] 7.0.3 spelling error
On Mon, 12 Feb 2001, Bruce Momjian wrote: > Done. Thanks! > > > > > On Mon, 12 Feb 2001, Christopher Kings-Lynne wrote: > > > > > I just got this error message in 7.0.3: > > > > > > ERROR: to_char/to_number(): not unique decimal poit. > > > > > > Might want to ensure it's correctly spelled in 7.1 > > > > Hmm, you are right. But I don't want prepare a patch with one > > char. > > > > Hackers, can anyone who will changing something in sources add > > 'n' to utils/adt/formatting.c, line 980 and correct 'poit' to > > 'point'. Please :-))) I haven't time now. > > > > Karel
Re: [HACKERS] 7.0.3 spelling error
Done. > > On Mon, 12 Feb 2001, Christopher Kings-Lynne wrote: > > > I just got this error message in 7.0.3: > > > > ERROR: to_char/to_number(): not unique decimal poit. > > > > Might want to ensure it's correctly spelled in 7.1 > > Hmm, you are right. But I don't want prepare a patch with one > char. > > Hackers, can anyone who will changing something in sources add > 'n' to utils/adt/formatting.c, line 980 and correct 'poit' to > 'point'. Please :-))) I haven't time now. > > Karel > > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] Bug: pgsql 7.0.2 cursor bug
Hello, I just saw (or better to say waspointed to) the following bug in Bug tracking tool submitted yesterday: pgsql 7.0.2 cursor bug. I have exactly the same trouble... Until I free cursor daemon grows... I have this in plain 7.0.3. Any comments? -- Sincerely Yours, Denis Perchine -- E-Mail: [EMAIL PROTECTED] HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 --
Re: [HACKERS] 7.0.3 spelling error
On Mon, 12 Feb 2001, Christopher Kings-Lynne wrote: > I just got this error message in 7.0.3: > > ERROR: to_char/to_number(): not unique decimal poit. > > Might want to ensure it's correctly spelled in 7.1 Hmm, you are right. But I don't want prepare a patch with one char. Hackers, can anyone who will changing something in sources add 'n' to utils/adt/formatting.c, line 980 and correct 'poit' to 'point'. Please :-))) I haven't time now. Karel