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
[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
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
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
[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] 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 as lib/dllist.h, that are needed on the client side only because libpq-int.h includes them, and we
[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
[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
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] 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] 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 sql diagnostics information Ross
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/
[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
[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
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
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/
[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 table reference TR is contained in a from clause FC with no intervening derived table, then the scope clause SC of TR is the select statement: single row or innermost query specification that contains FC. The scope clause of the exposed correlation name or exposed table name of TR is the select list, where clause, group by clause, and having clause of SC, together with the join condition of all joined tables contained in SC that contains TR. b) Otherwise, the scope clause SC of TR is the outermost joined table that contains TR with no intervening derived table. The scope of the exposed correlation name or exposed table name of TR is the join condition of SC and of all joined tables contained in SC that contain TR. I mistakenly read this with the assumption that derived table means a sub-SELECT. It does mean that, but it also means a joined table, *if and only if* that joined table is labeled with a correlation name. The relevant productions are: table reference ::= table name [ [ AS ] correlation name [ left paren derived column list right paren ] ] | derived table [ AS ] correlation name [ left paren derived column list right paren ] | joined table derived table ::= table subquery table subquery ::= subquery subquery ::= left paren query expression right paren query expression ::= non-join query expression | joined table So "(joined table) AS foo" has a subquery but "joined table" doesn't. AFAICT, this means that table references defined within the join are invisible outside "(joined table) AS foo", but they are visible outside a plain "joined table". 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
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
[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 ./
[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. Snip 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.
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/
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
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
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
[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 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] 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 string.h
#include locale.h
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] 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]
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] 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] 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!!!
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
