Re: [HACKERS] palloc failures...still... - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: [HACKERS] palloc failures...still...
Date
Msg-id Pine.BSF.3.96.980410145424.290C-100000@thelab.hub.org
Whole thread Raw
In response to Re: [HACKERS] palloc failures...still...  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
On Fri, 10 Apr 1998, Bruce Momjian wrote:

> > Apr 10 01:59:47 clio radiusd[22585]: query failed: select uniq_id from \
> >     radlog where uniq_id='237286618' and stop_time=0 and \
> >     term_server='isdn-1.trends.ca';
> > Apr 10 01:59:47 clio radiusd[22585]: query failed: FATAL 1:  palloc \
> >     failure: memory exhausted
> >
> >
> >     And, I'm still getting alot of:
> >
> > FATAL 1:  btree: BTP_CHAIN flag was expected
> > FATAL 1:  btree: BTP_CHAIN flag was expected
> > FATAL 1:  btree: BTP_CHAIN flag was expected
> > FATAL 1:  btree: BTP_CHAIN flag was expected
> > FATAL 1:  btree: BTP_CHAIN flag was expected
> > FATAL 1:  btree: BTP_CHAIN flag was expected
> > FATAL 1:  btree: BTP_CHAIN flag was expected
> > FATAL 1:  btree: BTP_CHAIN flag was expected
> > FATAL 1:  btree: BTP_CHAIN flag was expected
> >
>
> Man, Marc, you get the strangest errors.  Time for dump/restore to clean
> up whatever strangeness you have in that database.

    that is easier said then done :(  the last time I did do that, but
the problem creeped back again...but even ignoring the BTP_CHAIN error,
what about the palloc failure still?

    Guess I just found my "release trigger"...this database working
properly :)


Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] palloc failures...still...
Next
From: Peter T Mount
Date:
Subject: Re: [HACKERS] New pg_type for large object