Re: [BUGS] rm -rf in initlocation violates Rule of Least Surprise
On Fri, 2003-10-24 at 22:59, Clifford T. Matthews wrote: > Using initlocation from postgresql 7.3.4 I managed to blow away some > important data tonight due to "exit_nicely"'s "rm -rf". Has there been any followup on this? IMHO this is a bug we should fix. -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] Repeatedly breaking indexes
On Nov-04 2003, Tue, 07:07 +0100 Martin Edlman <[EMAIL PROTECTED]> wrote: > I use cs_CZ locale. But any of indexes we are talking about doesn't use > czech chars, furthermore even any of these tables doesn't contain czech > chars. Martin, you can probably rule out the cs_CZ (LATIN2) locale as the cause of your problems -- I've been using that one for years on many production postgres systems (often huge and constantly loaded) and have never observed the problems you're describing. -- Tomas Szepe <[EMAIL PROTECTED]> ---(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] Repeatedly breaking indexes
Tomas Szepe <[EMAIL PROTECTED]> writes: > Martin, you can probably rule out the cs_CZ (LATIN2) locale as the cause > of your problems -- I've been using that one for years on many production > postgres systems (often huge and constantly loaded) and have never observed > the problems you're describing. Thanks for the info. But are you using cs_CZ.ISO8859-2 in particular on Red Hat 8.0 in particular? If it is a locale-related issue, it might be specific to that particular variant on that platform. I have RH 8.0 here, and could easily run some tests, but I'm not sure what to look for. A quick run of the regression tests didn't reveal any issues, other than expectable differences from C locale in sort ordering. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] rm -rf in initlocation violates Rule of Least Surprise
Neil Conway <[EMAIL PROTECTED]> writes: > On Fri, 2003-10-24 at 22:59, Clifford T. Matthews wrote: >> Using initlocation from postgresql 7.3.4 I managed to blow away some >> important data tonight due to "exit_nicely"'s "rm -rf". > Has there been any followup on this? IMHO this is a bug we should fix. I'm disinclined to expend any effort at all on initlocation, since it's going to disappear when we have tablespaces ... which I would like to believe will happen for 7.5. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] Possible bug in conversion_create.sql
"" <[EMAIL PROTECTED]> writes: >> It's not supposed to. I don't know what problem you had, but this is >> the wrong fix. > But the problem was solved with the change. I'm not a postgres master > at all, so, how postgres knows what to use on the libdir variable? > Where the variable is defined? How I know if this is set? $libdir is expanded on-the-fly when the dynamic function loader needs to find the file. The value that is used for it can be found from pg_config --pkglibdir regards, tom lane ---(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] Repeatedly breaking indexes
On Nov-04 2003, Tue, 09:24 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: > Tomas Szepe <[EMAIL PROTECTED]> writes: > > Martin, you can probably rule out the cs_CZ (LATIN2) locale as the cause > > of your problems -- I've been using that one for years on many production > > postgres systems (often huge and constantly loaded) and have never observed > > the problems you're describing. > > Thanks for the info. But are you using cs_CZ.ISO8859-2 in particular on > Red Hat 8.0 in particular? If it is a locale-related issue, it might be > specific to that particular variant on that platform. Slackware 7.1 -> 9.1, which directly translates to vanilla glibc. -- Tomas Szepe <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Possible bug in conversion_create.sql
>> With the help of two people from #postgresql at irc.freenode.org, I did a >> initdb -d --pgdata data 2>debug.log and founded out that the problem was >> that conversion_create.sql wasn't changing $libdir to the actual name > It's not supposed to. I don't know what problem you had, but this is > the wrong fix. I'm sure that sed isn't the correct procedure :-) Somewhere in the way (in the instalation or in runtime), postgres should change libdir to the actual dir name, since the error was "no such file or directory"... But the problem was solved with the change. I'm not a postgres master at all, so, how postgres knows what to use on the libdir variable? Where the variable is defined? How I know if this is set? Thanks for any anwer :-) Silvio Fonseca Linux Consultant ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] PostgreSQL 7.4RC1 crashes on Panther
I've encountered a problem where the PostgreSQL database crashes when attempting to load pltcl.so on Mac OS 10.3. PostgreSQL fails because memory cannot be allocated during a shmget call. Here is the exact error message: FATAL: could not create shared memory segment: Cannot allocate memory DETAIL: Failed system call was shmget(key=5432001, size=3809280, 03600). HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space. To reduce the request size (currently 3809280 bytes), reduce PostgreSQL's shared_buffers parameter (currently 300) and/or its max_connections parameter (currently 50). The PostgreSQL documentation contains more information about shared memory configuration. Here's the code that triggers it: create function pltcl_call_handler() RETURNS LANGUAGE_HANDLER as 'pltcl.so' language 'c'; I have 1GB of memory and very little running on the powerbook (I rebooted just to be sure I started with a clean system). Not sure whether this is a PostgreSQL problem or a Mac OS 10.3 problem, but I can load plpgsql.so right before loading pltcl.so and it still only fails on the pltcl.so load. Commenting out the plpgsql.so load and trying again it still fails on the pltcl.so load. I'm compiling against a locally compiled version of Tcl 8.4.4. Here are the configure settings: ./configure \ --prefix=$INSTALL/postgresql \ --with-tcl \ --with-tclconfig=$INSTALL/tcl/lib \ --with-includes=$INSTALL/tcl/include:$INSTALL/readline/include \ --with-libraries=$INSTALL/readline/lib \ --without-tk \ --without-openssl thanks, /s. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] PostgreSQL 7.4RC1 crashes on Panther
Scott Goodwin <[EMAIL PROTECTED]> writes: > FATAL: could not create shared memory segment: Cannot allocate memory > Here's the code that triggers it: > create function pltcl_call_handler() RETURNS LANGUAGE_HANDLER > as 'pltcl.so' language 'c'; I don't think so. That's a startup failure; it can not be triggered by executing a SQL command, because if the postmaster is alive enough to accept a SQL command in the first place, it's already gotten past creation of the shared memory segment. > Not sure whether this is a PostgreSQL problem or a Mac OS 10.3 problem, It's a user problem. If you're going to run multiple shared-memory-using applications, it's up to you to adjust the kernel limit or the per-application requests to fit. I can't tell from this what other app is using shared memory, though. Are you trying to start more than one postmaster? If not, see whether OS X provides "ipcs" --- that would give you some data about what shared-memory requests are already present in the system. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
