From: | Medi Montaseri <medi(dot)montaseri(at)intransa(dot)com> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | Francisco Reyes <lists(at)natserv(dot)com>, pgsql General List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Closing inactive connections OR user connections limits |
Date: | 2002-11-20 22:47:39 |
Message-ID: | 3DDC110B.3030502@intransa.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-sql |
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(dot)montaseri(at)intransa(dot)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
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | scott.marlowe | 2002-11-20 23:12:56 | Re: Closing inactive connections OR user connections limits |
Previous Message | Brian Minton | 2002-11-20 22:36:34 | Re: get_bit etc. |
From | Date | Subject | |
---|---|---|---|
Next Message | scott.marlowe | 2002-11-20 23:12:56 | Re: Closing inactive connections OR user connections limits |
Previous Message | Josh Berkus | 2002-11-20 22:27:41 | Re: trying to learn plpqsql... so please forgive.. |