Re: Important 7.0.* fix to ensure buffers are released

> Hiroshi Inoue pointed out that Postgres neglects to do an explicit
> transaction abort during backend shutdown.  For example, in psql
>     begin;
>     declare myc cursor for select * from ..;
>     fetch in myc;
>     \q
> would cause the backend to exit without having released the resources
> acquired for the open transaction.  This is OK from the point of view
> of data integrity (other transactions will believe that the transaction
> was aborted) but not OK if shared resources are left locked up.  In
> particular, this oversight probably accounts for the sporadic reports
> we've seen of errors like
>
> NOTICE:  FlushRelationBuffers(all_flows, 500237): block 171439 is
> referenced (private 0, global 1)
> FATAL 1:  VACUUM (vc_repair_frag): FlushRelationBuffers returned -2
>
> since shared buffer reference counts would not be released by an
> exiting backend, leading to a complaint (perhaps much later) when
> VACUUM checks that there are no references to the relation it's
> trying to vacuum.

Interesting thing is that 6.5.x does not have the problem. Is it new
one for 7.0.x?

I remember that you have fixed some refcount leaks in 6.5.x. Could you
tell me any examples to demonstrate the cases in 6.5.x, those are
supposed to be fixed in 7.0.x? I just want to know what kind of
refcount leak problems existing in 6.5.x and 7.0.x.
--
Tatsuo Ishii