Re: BUG #10155: BUG? Cann't remove new generated tuples after repeatable read transaction start.
От | Heikki Linnakangas |
---|---|
Тема | Re: BUG #10155: BUG? Cann't remove new generated tuples after repeatable read transaction start. |
Дата | |
Msg-id | 535EA3AD.6070209@vmware.com обсуждение исходный текст |
Ответ на | BUG #10155: BUG? Cann't remove new generated tuples after repeatable read transaction start. (digoal@126.com) |
Ответы |
Re: BUG #10155: BUG? Cann't remove new generated tuples
after repeatable read transaction start.
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: