> 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
