From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Thomas Reinke <reinke(at)e-softinc(dot)com> |
Cc: | mirko(dot)kaffka(at)interface-business(dot)de, pgsql-general(at)postgreSQL(dot)org, PostgreSQL Hackers <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [GENERAL] backend dies suddenly after a lot of error messages |
Date: | 1999-07-07 03:25:46 |
Message-ID: | 199907070325.XAA02373@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
> > We have problems with backend processes that close the channel because of
> > palloc() failures. When an INSERT statement fails, the backend reports an
> > error (e.g. `Cannot insert a duplicate key into a unique index') and
> > allocates a few bytes more memory. The next SQL statement that fails
> > causes the backend to allocate more memory again, etc. until we have no
> > more virtual memory left. Is this a bug?
> > We are using postgres 6.4.2 on FreeBSD 2.2.8.
> >
> > It also works with psql:
> >
> > toy=> create table mytable (i integer unique);
> > NOTICE: CREATE TABLE/UNIQUE will create implicit index mytable_i_key for
> > table mytable
> > CREATE
> > toy=> \q
> >
> > ~ $ # now do a lot of inserts that cause error messages:
> > ~ $ while true; do echo "INSERT INTO mytable VALUES (1);"; done | psql toy
> > INSERT INTO mytable VALUES (1);
> > ERROR: Cannot insert a duplicate key into a unique index
> > ...quite a lot of these messages
> > INSERT INTO mytable VALUES (1);
> > ERROR: Cannot insert a duplicate key into a unique index
> > INSERT INTO mytable VALUES (1);
> >
> > pqReadData() -- backend closed the channel unexpectedly.
> > This probably means the backend terminated abnormally before or
> > while processing the request.
> > We have lost the connection to the backend, so further processing is
> > impossible. Terminating.
> >
> > Hmm, why does the backend allocate more and more memory with each failed
> > INSERT ?
> > Any clues?
There was a bug in pre-6.5 versions that caused elog failure not to
release their memory. There is still a small leak for elogs, but it is
only a few bytes. You should find this is fixed in 6.5.
--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-07-07 03:49:21 | Re: [GENERAL] JoinClauseSelecivity: bad value |
Previous Message | Bruce Momjian | 1999-07-07 03:24:12 | Re: [GENERAL] Problems with inequalities on numeric fields in 6.5 |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-07-07 03:38:37 | Bug tracking |
Previous Message | Bruce Momjian | 1999-07-07 03:21:03 | Re: [HACKERS] defalut value |