Re: Fwd: Postgres update

From: Denis Perchine <dyp(at)perchine(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fwd: Postgres update
Date: 2000-07-28 15:12:06
Message-ID: 0007282220050I.18993@dyp.perchine.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > NOTICE: FlushRelationBuffers(pg_largeobject, 515): block 504 is referenced (private 0, global 1)
> > FATAL 1: VACUUM (repair_frag): FlushRelationBuffers returned -2
>
> Hmm, there's another report of that in the archives. You've got a
> buffer that has a positive reference count even though (presumably)
> no one is using it. VACUUM is quitting out of paranoia that maybe
> some other backend is accessing the table --- there's unlikely to be
> any actual data corruption here, just (over?) caution.
>
> You can get back to a state where VACUUM will work on the table by
> restarting the postmaster, but to fix the real problem we need to figure
> out how the system got into this state in the first place. Can you
> produce a repeatable example of a series of queries that gets you into
> this state?

I get this after the following:
psql:/home/www/www.webmailstation.com/sql/reindex.sql:75: NOTICE: !!! write error seems permanent !!!psql:/home/www/www.webmailstation.com/sql/reindex.sql:75: NOTICE: !!! now kill all backends and reset postmaster !!!
psql:/home/www/www.webmailstation.com/sql/reindex.sql:75: ERROR: cannot write block 175 of ix_q_b_1 [webmailstation] blind
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
psql:/home/www/www.webmailstation.com/sql/reindex.sql:75: connection to server was lost

This was the command which should create unique index. Something happend and
index became corrupted. After that postgres starts to eat up memory and I killed him.
I recognized that this happend on update of the table on which the index was build and
that update uses the index.

It is hard to reproduce this...
I would like to give you binary data, but unfortunatly I was forced
to rebuild index ASAP and has finished investigation later...

--
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp(at)perchine(dot)com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2000-07-28 15:24:58 Re: Questionable coding in proc.c & lock.c
Previous Message Tom Lane 2000-07-28 15:10:14 Re: toasting for other varlena types