Re: Fwd: Postgres update

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

Denis Perchine <dyp(at)perchine(dot)com> writes:
>>>> NOTICE: FlushRelationBuffers(pg_largeobject, 515): block 504 is referenced (private 0, global 1)
>>>> FATAL 1: VACUUM (repair_frag): FlushRelationBuffers returned -2

> I get this after the following:

> NOTICE: !!! write error seems permanent !!!
> NOTICE: !!! now kill all backends and reset postmaster !!!
> ERROR: cannot write block 175 of ix_q_b_1 [webmailstation] blind
> pqReadData() -- backend closed the channel unexpectedly.

Oh, that's interesting. The NOTICEs are coming out of AbortBufferIO()
which is invoked during error processing (in other words, I bet the
ERROR actually happened first. It's a libpq artifact that the NOTICEs
are presented first on the client side. If you are keeping the
postmaster log output you could confirm the sequence of events by
looking in the log). The backend shutdown is then forced by
AbortBufferIO().

AbortBufferIO() seems rather badly designed, but given that it forces
a database-wide restart, I'm not sure how this could relate to the
later FlushRelationBuffers problem. The restart should get rid of the
old buffers anyway.

> This was the command which should create unique index.

Was the index on the same table that FlushRelationBuffers later had
trouble with (ie, "pg_largeobject")?

What version are you running, anyway? There is no "pg_largeobject"
in either 6.5 or current AFAIK.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Henry B. Hotz 2000-07-28 18:39:27 Re: mac.c
Previous Message Tom Lane 2000-07-28 17:36:35 Re: pg_dump & performance degradation