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: EKEJJICOHDIEMGPNIFIJKECICDAA.Inoue@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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
running.

Regards.

Hiroshi Inoue

In response to

Responses

Browse pgsql-hackers by date

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