Re: Closing inactive connections OR user connections limits - Mailing list pgsql-general

From Medi Montaseri
Subject Re: Closing inactive connections OR user connections limits
Date
Msg-id 3DDC110B.3030502@intransa.com
Whole thread Raw
In response to Re: Closing inactive connections OR user connections limits  (Francisco Reyes <lists@natserv.com>)
Responses Re: Closing inactive connections OR user connections limits  ("scott.marlowe" <scott.marlowe@ihs.com>)
List 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 by date:

Previous
From: Brian Minton
Date:
Subject: Re: get_bit etc.
Next
From: "scott.marlowe"
Date:
Subject: Re: Closing inactive connections OR user connections limits