Re: BUG #10155: BUG? Cann't remove new generated tuples after repeatable read transaction start.

   This is so bad in pg_dump use, when a database so big.

   because pg_dump is also use repeatable read isolation. and when pg_dump backup database , the database will bloat .

   Can we optimize it?

At 2014-04-29 02:53:33,"Heikki Linnakangas" <hlinnakangas@vmware.com> wrote:
>On 04/28/2014 11:37 AM, digoal@126.com wrote:
>> SESSION B :
>> but B cann't reclaim rows from table t.
>> why?
>> i think postgresql cann't reclaim tuples already exists before repeatable
>> read transaction start, why this case t's tuples after session a and cann't
>> reclaim.
>
>I think what you're arguing is that the system should be smarter and be 
>able to reclaim the dead tuples. Because session A began before the 
>table was even created, and there are no other backends that would need 
>to see them either, they could indeed be safely vacuumed. The system 
>just isn't smart enough to distinguish the case.
>
>The short answer is that such an optimization just doesn't exist in 
>PostgreSQL. It's certainly not a bug.
>
>The long answer is that actually, even though the table was created 
>after the transaction in session A began, session A *can* access the 
>table. Schema changes don't follow the normal MVCC rules. If you do 
>"SELECT * FROM t" in session A, it will work. However, the rows still 
>won't be visible, to sessin A, because they were inserted after the 
>snapshot was taken, so they could still be vacuumed if the system 
>tracked the snapshots more carefully and was able to deduce that. But 
>the fact that a new table was created is not relevant.
>
>- Heikki