From: | Adriaan Joubert <a(dot)joubert(at)albourne(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | BlowAwayRelationBuffers |
Date: | 2000-01-12 07:50:10 |
Message-ID: | 387C3232.85F1E291@albourne.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hmmm, I got the following this morning on version 6.5.2 on DEC Alpha
during a vacuum verbose analyze. Ended up with duplicate rows of
everything.
NOTICE: --Relation tasksids--
NOTICE: Pages 1356: Changed 349, Reapped 875, Empty 0, New 0; Tup
88946: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 123921, MinLen 41, MaxLen
41; Re-using: Free/Avail. Space 5965708/5965708; EndEmpty/Avail. Pages
0/875. Elapsed 0/0 sec.
NOTICE: Rel tasksids: Pages: 1356 --> 567; Tuple(s) moved: 31746.
Elapsed 0/0 sec.
NOTICE: BlowawayRelationBuffers(tasksids, 567): block 764 is referenced
(private 0, last 0, global 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.
According to the mailing list archive
http://www.postgresql.org/mhonarc/pgsql-hackers/1999-02/msg00052.html
a bug in this area was fixed in 6.4. I seem to remember that somebody is
looking at vacuum at the moment, so this may be something to keep in
mind.
Adriaan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-01-12 08:24:42 | Re: [HACKERS] BlowAwayRelationBuffers |
Previous Message | Tom Lane | 2000-01-12 07:01:58 | Re: INDEX_MAX_KEYS = 16 ... it works, too |