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
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 t
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 describi
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
"" <[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? H
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
>> 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
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
DET
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
