Re: Closing inactive connections OR user connections limits
От | Medi Montaseri |
---|---|
Тема | Re: Closing inactive connections OR user connections limits |
Дата | |
Msg-id | 3DDC110B.3030502@intransa.com обсуждение исходный текст |
Ответ на | Re: Closing inactive connections OR user connections limits (Francisco Reyes <lists@natserv.com>) |
Ответы |
Re: Closing inactive connections OR user connections limits
|
Список | pgsql-general |
Its my understanding that vacuum actually removes tuples that have been updated or deleted. Sort of like emptying your trash .... whence a tuple has been removed, no rollback can set the state back. If you have logically removed a tuple (not vacuumed yet), then one can rollback, but if you vacuum then you can not rollback. Now suppose transaction A decides to delete some tuples, a vacuum job comes along and deletes things (in parallel), trans A decides to rollback....engines who support parallel vacuum-ing and transactions such as PG 7.2 better have a way of protecting themselves against this.... Correct me if ... Neil Conway wrote: >Medi Montaseri <medi.montaseri@intransa.com> writes: > > >>I think from the data integrity point of view, vacuum is more >>important than vacuum full. >> >> > >Why would VACUUM have any effect on data integrity, either positive or >negative? > >Cheers, > >Neil > > >
В списке pgsql-general по дате отправления: