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
