Skip site navigation (1) Skip section navigation (2)

RE: Fwd: Postgres update

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>, "Denis Perchine" <dyp(at)perchine(dot)com>
Subject: RE: Fwd: Postgres update
Date: 2000-07-28 22:35:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> -----Original Message-----
> From: pgsql-hackers-owner(at)hub(dot)org [mailto:pgsql-hackers-owner(at)hub(dot)org]On
> Behalf Of Tom Lane
> 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

It was me who introduced xxxxBufferIO routines to avoid io_in_progress
spinlock freezing. Unfortunately I didn't think of any elegant way to
recover parmanent write error then. I'm judging the error is parmanent
when write error for the buffer occurs twice.
Because you changed bufmgr before 7.0,we may be able to avoid a
database-wide restart.  However don't we have to leave the buffer 
still dirty even after your change ?  If I recognize correctly,we couldn't
know which backends dirtied the buffer.  Even though we could know
it,we couldn't know if the transactions which dirtied the buffer are still


Hiroshi Inoue

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2000-07-28 22:47:24
Subject: Re: Fwd: Postgres update
Previous:From: Tom LaneDate: 2000-07-28 22:10:11
Subject: bufmgr and smgr don't talk to each other, apparently

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group