[BUGS] BUG #2297: plpgsql function causes disconnect sometimes
The following bug has been logged online:
Bug reference: 2297
Logged by: bernd
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.3
Operating system: Linux Fedora Core 3
Description:plpgsql function causes disconnect sometimes
Details:
I'm trying to make some admin functions that I can use to revoke privileges
from users. The functions are all stored in a schema called admin. Here are
the functions:
---
create or replace function admin.fn_show_functions(text)
returns setof text as $$
declare
v_schema alias for $1;
v_schema_oid oid;
v_function pg_catalog.pg_proc%rowtype;
v_function_arg text;
v_function_name_and_args text;
begin
select into v_schema_oid oid
from pg_catalog.pg_namespace
where nspname = v_schema;
if found then
for v_function in select * from pg_catalog.pg_proc
where pronamespace = v_schema_oid
loop
v_function_name_and_args := v_function.proname || '(';
for i in 0..(v_function.pronargs - 1)
loop
select into v_function_arg typname
from pg_catalog.pg_type
where oid = v_function.proargtypes[i];
if v_function_arg is not null then
v_function_name_and_args := v_function_name_and_args ||
v_function_arg || ', ';
end if;
end loop;
v_function_name_and_args := trim(trailing ', ' from
v_function_name_and_args);
v_function_name_and_args := v_function_name_and_args || ')';
return next v_function_name_and_args;
end loop;
end if;
return;
end;
$$
language plpgsql;
---
create or replace function admin.fn_revoke_all_functions_from(text, text)
returns void as $$
declare
v_user alias for $1;
v_schema alias for $2;
v_obj record;
begin
for v_obj in select * from admin.fn_show_functions(v_schema) as
name
loop
raise notice 'revoking function %', v_obj.name;
execute 'revoke all on function ' ||
quote_ident(v_schema) || '."' ||
replace(v_obj.name, '(', '"(') || ' from ' ||
quote_ident(v_user);
end loop;
end;
$$
language plpgsql;
---
create or replace function admin.fn_revoke_all(text)
returns void as $$
declare
v_user alias for $1;
v_schema record;
v_obj record;
v_current_db text;
begin
for v_schema in select * from admin.fn_show_user_schemas() as name
loop
raise notice 'revoking all functions from % in %', v_user,
v_schema.name;
perform admin.fn_revoke_all_functions_from(v_user, v_schema.name);
end loop;
end;
$$
language plpgsql;
---
create or replace function admin.fn_show_user_schemas()
returns setof text as $$
declare
v_schema pg_catalog.pg_namespace%rowtype;
begin
for v_schema in select * from pg_catalog.pg_namespace
where not (nspname like 'pg_%' or nspname like 'information_schema')
loop
return next v_schema.nspname;
end loop;
end;
$$
language plpgsql;
---
When I execute:
SELECT * FROM admin.fn_revoke_all('someuser');
I sometimes get disconnected with this message:
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>
and in the log I have:
LOG: server process (PID 16202) was terminated by signal 11
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing
LOG: database system was interrupted at 2006-03-02 10:50:01 CST
LOG: checkpoint record is at 0/D004564
LOG: redo record is at 0/D004564; undo record is at 0/0; shutdown FALSE
LOG: next transaction ID: 26852; next OID: 101599
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: database system was not properly shut down; automatic recovery in
progress
LOG: connection received: host=[local]
FATAL: the database system is starting up
LOG: redo starts at 0/D0045A8
LOG: record with zero length at 0/D037BCC
LOG: redo done at 0/D037BA4
LOG: database system is ready
Since I have some RAISE NOTICE statements, I can see that the function
fn_revoke_all disconnects me right after it finishes revoking on all the
functions.
I have reproduced this behaviour on another machine with PostgreSQL 8.1.1
running CentOS 3. It doesn't matter which database I use, the result is the
same.
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2850: Cannot select from information_schema.schemat
--On Donnerstag, Dezember 21, 2006 15:47:40 + Tony Marston <[EMAIL PROTECTED]> wrote: The fact that the SQL standard says that the schemata view is supposed to "Identify the schemata in a catalog that are owned by a given user" does not automatically mean that the information can *ONLY* be accessed by the owner. Any user should be able to see the schema to which they have access, owner or not. The standard doesn't specify any given user, it specifies CURRENT_USER. Only if CURRENT_USER is the owner of a schema (or CURRENT_USER inherits ownership by membership) you are able (and allowed) to see the schema. While I admit that this makes it hard to identify catalog schemata by an DBA via the information_schema, the standard is quite clear here. I don't see any ambiguity here If you need to go beyond what the standard allows, you have to use the system catalog. -- Thanks Bernd ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[BUGS] BUG #3255: Proper escaping missing
The following bug has been logged online: Bug reference: 3255 Logged by: Bernd Fuhrmann Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4 Operating system: Windows XP SP2 Description:Proper escaping missing Details: I just tried to use pgAdmin to create a database with a stupid name: test"test This doesn't work since sends this: CREATE DATABASE "test"test" WITH ENCODING='UTF8'; Obivously, if I just enter 'test"test' into the field it rather should have sent this: CREATE DATABASE "test""test" WITH ENCODING='UTF8'; So I guess pg3Admin is missing proper escaping. Btw. using the name test""test created the database I wanted, but that will lead to a lot of other troubles when administrating that database with pgAdmin. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
--On 4. Juni 2010 15:19:42 -0400 Bruce Momjian wrote: That would make the bug go away, rather than require users to use a special flag (and find out only after they were doing the reload). Out of curiosity, why is this a "bug" now? We recommend migration procedures always to use the pg_dump of the newer version because of many reasons as clearly stated here: <http://www.postgresql.org/docs/8.4/interactive/migration.html> And wouldn't introducing backpatching such behavorial changes to pg_dump violate our policy in *not* to change such things in minor releases? (think of diff's against schema-only dumps and so on). Bernd -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5555: ALTER TABLE ONLY ... SET NOT NULL on parent prevent prior inherited tables from being restored
--On 12. Juli 2010 14:39:19 -0400 Tom Lane wrote: Yeah. Past discussions of this have leaned to the viewpoint that we should disallow the above, ie it should not be possible to have NOT NULL on the parent unless all the children have it too. Nobody's got round to implementing it though. There's a TODO item for it: see "Move NOT NULL constraint information to pg_constraint" FYI, i'm currently working on it, see <https://commitfest.postgresql.org/action/patch_view?id=312> Bernd -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Psql malloc error on Git master
--On 20. Januar 2011 21:56:44 + Thom Brown wrote: Known bug in OSX's libedit. Use readline instead. http://archives.postgresql.org/pgsql-bugs/2010-04/msg00127.php regards, tom lane How do I force readline? I'm not using --with-libedit-preferred or --without-readline What I've done is to switch to MacPorts[1] and use their packaging. I'm building PostgreSQL then with: --with-libraries=/opt/local/lib --with-includes=/opt/local/include which for example links psql/libreadline with: % otool -L $PGSQL_HOME/bin/psql /Users/bernd/pgsql-dev/install/HEAD/bin/psql: /Users/bernd/pgsql-dev/install/HEAD/lib/libpq.5.dylib (compatibility version 5.0.0, current version 5.4.0) /opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.1.0) /opt/local/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libreadline.6.1.dylib (compatibility version 6.0.0, current version 6.1.0) Works quite well for me. There's also a libedit in MacPorts, but i've never used it. Bernd [1] <http://www.macports.org/> -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Warm Standby startup process unconditionally hangs
PostgreSQL is 8.4.7, WAL-Logshipping is actually using SkyTools 2.1.12 (both installed from PGDG rpms), running with CentOS 5.5 XEN-VM with Kernel 2.6.18-194.26.1.el5xen. recovery.conf on the standby installed by walmgr is restore_command = '/usr/bin/walmgr.py /media/pgarchive/wal-config/wal-slave.ini xrestore %f "%p" %r' #recovery_target_time= #recovery_target_xid= #recovery_target_inclusive=true #recovery_target_timeline= The archive is located on a NFS share. We have seen the following happening on a PostgreSQL Warm Standby: Once for a while the Startup Process just stops recovering from archive. No more xlogs replayed, no more activity in the logs from the startup process. We've seen this two or three times in the past, this time we had the chance to do some further investigation what's happening. strace shows the startup process hanging with strace -p 31898 Process 31898 attached - interrupt to quit semop(425990, 0x7fff19919060, 1 Here is a backtrace from the startup process: (gdb) bt #0 0x003e214d5337 in semop () from /lib64/libc.so.6 #1 0x005a7ff3 in PGSemaphoreLock (sema=0x2b35a0140ce8, interruptOK=1 '\001') at pg_sema.c:420 #2 0x005c68a5 in LockBufferForCleanup (buffer=78428) at bufmgr.c:2467 #3 0x00485446 in RestoreBkpBlocks (lsn=, record=0xcf2b830, cleanup=1 '\001') at xlog.c:3292 #4 0x00460ce0 in heap2_redo (lsn=..., record=0x7fff19919060) at heapam.c:4805 #5 0x00482eff in StartupXLOG () at xlog.c:5665 #6 0x00484cfb in StartupProcessMain () at xlog.c:8102 #7 0x0049b5a8 in AuxiliaryProcessMain (argc=2, argv=optimized out>) at bootstrap.c:419 #8 0x005b0ef9 in StartChildProcess (type=StartupProcess) at postmaster.c:4319 #9 0x005b30c7 in PostmasterMain (argc=5, argv=0xcf079e0) at postmaster.c:1036 #10 0x0056079e in main (argc=5, argv=) at main.c:188 Looking at the code, it seems it is stuck in waiting for UnpinBuffer(), ProcWaitForSignal(). Getting the backtrace for the bgwriter process, it seems it is working as expected: (gdb) #0 0x003e214cd1c3 in __select_nocancel () from /lib64/libc.so.6 #1 0x006b086a in pg_usleep (microsec=) at pgsleep.c:43 #2 0x005ac00e in BackgroundWriterMain () at bgwriter.c:538 #3 0x0049b5b7 in AuxiliaryProcessMain (argc=2, argv=optimized out>) at bootstrap.c:424 #4 0x005b0ef9 in StartChildProcess (type=BgWriterProcess) at postmaster.c:4319 #5 0x005b4df6 in sigusr1_handler (postgres_signal_arg=optimized out>) at postmaster.c:4095 #6 #7 0x003e214cd1c3 in __select_nocancel () from /lib64/libc.so.6 #8 0x005b1b5e in ServerLoop () at postmaster.c:1347 #9 0x005b30dc in PostmasterMain (argc=5, argv=0xcf079e0) at postmaster.c:1040 #10 0x0056079e in main (argc=5, argv=) at main.c:188 The logfile shows the following sequence before this issue: <@ 2011-03-21 13:56:46 CET 4d7a3ae1.7c9a-1457> LOG: restored log file "000100200070" from archive <@ 2011-03-21 13:56:46 CET 4d7a3ae2.7c9e-48794> DEBUG: updated min recovery point to 20/704A6EC8 <@ 2011-03-21 13:56:46 CET 4d7a3ae2.7c9e-48795> CONTEXT: writing block 157 of relation base/70631854/70632521 <@ 2011-03-21 13:56:46 CET 4d7a3ae2.7c9e-48796> DEBUG: updated min recovery point to 20/7054BD78 <@ 2011-03-21 13:56:46 CET 4d7a3ae2.7c9e-48797> CONTEXT: writing block 156 of relation base/70631854/70632521 <@ 2011-03-21 13:57:03 CET 4d7a3ae2.7c9e-48798> LOG: restartpoint complete: wrote 4518 buffers (1.7%); write=225.415 s, sync=0.203 s, total=225.621 s <@ 2011-03-21 13:57:03 CET 4d7a3ae2.7c9e-48799> LOG: recovery restart point at 20/68244EC8 <@ 2011-03-21 13:58:18 CET 4d7a3ae2.7c9e-48800> LOG: restartpoint starting: time <@ 2011-03-21 14:02:18 CET 4d7a3ae2.7c9e-48801> LOG: restartpoint complete: wrote 3733 buffers (1.4%); write=239.997 s, sync=0.022 s, total=240.022 s <@ 2011-03-21 14:02:18 CET 4d7a3ae2.7c9e-48802> LOG: recovery restart point at 20/6BEB2EB0 <@ 2011-03-21 14:03:18 CET 4d7a3ae2.7c9e-48803> DEBUG: skipping restartpoint, already performed at 20/6BEB2EB0 <@ 2011-03-21 14:03:33 CET 4d7a3ae2.7c9e-48804> DEBUG: skipping restartpoint, already performed at 20/6BEB2EB0 <@ 2011-03-21 14:03:48 CET 4d7a3ae2.7c9e-48805> DEBUG: skipping restartpoint, already performed at 20/6BEB2EB0 After this, the startup process just "hangs", with the symptoms shown above. I need to restart the standby now, because the customer wants to have it back as soon as possible, but if you need more infos, please let me know. -- Thanks Bernd -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Warm Standby startup process unconditionally hangs
--On 23. März 2011 20:37:11 + Simon Riggs wrote: The patches are slightly different because the infrastructure isn't all there in 8.4. Please can you test these before I commit to 8.4. FYI, we have deployed patched RPMs to one of the standby servers, the one where most of the hangs occured in the past. We'll see wether we get further hangs there. Bernd -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6024: pg_dump won't dump ALTERed inherited fields
--On 12. Mai 2011 11:24:13 -0400 Tom Lane wrote: This is on the to-fix list --- in fact there was a patch submitted for it last year, although it got returned for rework and we've not seen it again yet. Yes, I didn't manage to provide a completed patch for 9.1...will try to re-submit for 9.2, it's on my radar again. -- Thanks Bernd -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6066: Bad string in German translation causes segfault (user-triggerable)
--On 17. Juni 2011 08:18:03 + Christoph Berg wrote:
In German locale, the follow statement causes vsnprintf() to segfault when
printing the hint:
SELECT TO_DATE('30.12.2011', 'MMDD') AS datum;
Fix tested for 8.4:
Additionally, this seems to be the case for 9.0, 9.1 and current -HEAD, too.
--
Thanks
Bernd
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6113: SET DATESTYLE='European' does not set datestyle output correctly
--On 12. Juli 2011 04:32:11 + David Carlos Manuelda wrote: The following bug has been logged online: Bug reference: 6113 Logged by: David Carlos Manuelda Email address: stormb...@gmail.com PostgreSQL version: 9.0.4 Operating system: Gentoo Linux Description:SET DATESTYLE='European' does not set datestyle output correctly Details: According to Doc (http://www.postgresql.org/docs/7.2/static/sql-set.html), there are different datestyles available to format date outputs. This is a very outdated documentation link, you should refer to the 9.0 documentation instead: <http://www.postgresql.org/docs/9.0/static/runtime-config-client.html#RUNTIME-CONFIG-CLIENT-FORMAT> But either is a bug in doc or is a bug in postgre itself, but 'European' does not currently do what it is intended (it does nothing actually). [...] As you can see, SET DATESTYLE='European' just did nothing and did not change it from last set which was 'German', and of course, it does not even outputs what was expected and stated in documentation. 'European' or 'Euro' is just another way to write 'DMY' as an input format for the date part. At least, for me it works as expected: SET datestyle TO 'ISO, mdy'; SELECT '27.12.2011'::date; ERROR: 22008: date/time field value out of range: "27.12.2011" at character 8 HINT: Perhaps you need a different "datestyle" setting. LOCATION: DateTimeParseError, datetime.c:3541 STATEMENT: SELECT '27.12.2011'::date; ERROR: date/time field value out of range: "27.12.2011" LINE 1: SELECT '27.12.2011'::date; ^ HINT: Perhaps you need a different "datestyle" setting. SET datestyle TO 'European'; SHOW datestyle; DateStyle --- ISO, DMY (1 row) SELECT '27.12.2011'::date; date 2011-12-27 (1 row) -- Thanks Bernd -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Warm Standby startup process unconditionally hangs
--On 23. März 2011 20:37:11 + Simon Riggs wrote: The patches are slightly different because the infrastructure isn't all there in 8.4. Please can you test these before I commit to 8.4. Hi Simon, I've searched the committers mailinglist wether this is already committed, but either i've missed one or this is still open? If not, sorry for bothering you... Our customers reports that with the patches applied they didn't had any further hangs on the standby instances anymore for the last couple of months now. -- Thanks Bernd -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7562: could not read block 0 in file "base/16385/16585": read only 0 of 8192 bytes
--On 20. September 2012 18:18:12 -0400 Tom Lane wrote: If it were an actual TRUNCATE, yeah. But it could be a case of VACUUM truncating a now-empty table to zero blocks. But nothing like this would explain the OP's report that corruption is completely reproducible for him. So I like your theory about hash index use better. We really oughta get some WAL support in there. We had a similar issue at a customer site. The server was shut down for updating it from 9.1.4 to 9.1.5, after starting it again the log was immediately cluttered with ERROR: could not read block 251 in file "base/6447890/7843708": read only 0 of 8192 bytes The index was a primary key on table with mostly INSERTS (only a few hundred DELETEs, autovacuum didn't even bother to vacuum it yet and no manual VACUUM). According to the customer, no DDL action takes place on this specific table. The kernel didn't show any errors. -- Thanks Bernd -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7562: could not read block 0 in file "base/16385/16585": read only 0 of 8192 bytes
--On 21. September 2012 10:25:50 +0200 Andres Freund
wrote:
We had a similar issue at a customer site. The server was shut down for
updating it from 9.1.4 to 9.1.5, after starting it again the log was
immediately cluttered with
How was it shutdown? -m fast or -m immediate?
-m fast
ERROR: could not read block 251 in file "base/6447890/7843708": read
only 0 of 8192 bytes
So, not block 0. How many blocks does the new index contain?
255 blocks according to its current size.
--
Thanks
Bernd
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8291: postgres_fdw does not re-read USER MAPING after change.
--On 9. Juli 2013 22:05:20 + lal...@fhcrc.org wrote: I have found that if you change the password in the USER MAPPING, that postgres_fdw will not use it unless the current password fails or you close and re-open your postgres connection. I found this while testing to see if the USER MAPPING's supports MD5 passwords and they appeared to until the next day when I found that they no longer worked because I had closed and re-opened my connection. Hmm i don't think that's a bug. It's because the postgres_fdw caches the connection within your local session, reusing it for any subsequent foreign table access. The second error that I found is in the documentation of ALTER USER MAPPING. It incorrectly says how to update a users password. It could be misread, i agree. Attached is a small doc patch to address this against HEAD. -- Thanks Bernd user_mapping_doc.patch Description: Binary data -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Postgre connection management
Hello, Annu Panesar wrote: hi i need help urgently to understand how postgres manages its connection pool , how it manages deadlock . we are using postgres for our supply chain mgmt system and we are facding connectin related problems.. plz cud u direct me to some relevant res ources/urls Please call this site: http://www.google.com and type "postgres connection pooling" in the text field, next press the "Google search" button - and choose one or another of the 2000 URLs that you receive. regards // Bernd vdB ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] 'query was cancelled' - depending on search pattern
Hello Bugs, a query that uses pattern matching like this: SELECT .. WHERE ( (content || authorname) ~* ( '.*gesellschaft.* | .*wirtschaft.*' ) ) produces an error 'Query was cancelled' - sometimes, depending on the search words. Seems quite strange to me, I increased some postgresql.conf parameters, without effect, and failed in finding anything on 'query was cancelled' in the docs or in google. Any hints are welcome (and an update to the docs about error messages would make sense anyway). // Bernd vdB ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] 'query was cancelled' - depending on search pattern
Hello Tom, At 04.04.2003 00:22, you wrote: Bernd von den Brincken <[EMAIL PROTECTED]> writes: > a query ... produces an error 'Query was cancelled' - > sometimes, depending on the search words. That's really, really hard to believe. I suspect you've mis-analyzed the situation. You sure your client-side code doesn't send cancel requests on occasion? Can you create a test case that would let someone else reproduce this behavior? I stripped the query down a bit - this one produces the cancel: SELECT id FROM cftext WHERE ( content ~* ( '.*wirt.* | .*weil.*' ) ) ; Whereas this one provides a correct result set: SELECT id FROM cftext WHERE ( content ~* ( '.*wirt.* | .*und.*' ) ) ; My client is psql via telnet on a Toshiba T550 laptop, my version(): PostgreSQL 7.3.2 on i386-portbld-freebsd4.7, compiled by GCC 2.95.4 Now I tested it on a different machine (P-3 Server) with (almost) the same DB contents - it works fine there ! - The version() says: PostgreSQL 7.3 on i386-unknown-freebsd4.5, compiled by GCC 2.95.3 So may the problem be in the pattern matching code that may differ between freebsd versions? Regards // Bernd vdB ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] commands
Hello, subbiah K wrote: i want how to start the postsql in redhat linux 8 & how to access the data base postgresql in linux i have ms access 2000 db its possible to access in linux go throw in postgresql would you please fill in some more letters in your request so we know what you really aim for. For the moment the only advice can be to read the docs. // Bernd vdB ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Make install error
Hello, Segree, Gareth wrote: Whenever I do a make install I get the following error: /usr/lib/postgresql/ascii_msc.so does not exist. Obvious, you have to install the ascii library before you can use postgres on your Nokia mobile phone. Regards // Bernd vdB ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
