On 22/04/2004, Guy Fraser <guy@incentre.net> wrote To pgsql-general@postgresql.org:What if your not the only person accessing the database and someone else has an active transaction that was initiated before your transaction was committed?
Shouldn't the Database server be the entity that decides when vacuum isHow is the database supposed to know when you want to purge records?
needed?
Once a vacuum has been run, the table can not be rolled back or time
traveled.
Hmm, if the UPDATE is in a transaction block. After this block is committed, the deleted tuple could be purged if there is a flag. Like, either in the schema 'purge-on-commit', or as an option like 'UPDATE PURGE'?
Just an idea.. (Brainfart?) :)
ciao
If you delete the 'stale' data, then you would have to abort their transaction or their transaction would have data with mixed results from before your update and after your update. When to remove 'stale' data is not a simple thing to determine in an active database. In order to preserve transactional integrity, all transactions that are being handled during the transaction that modifies the data, must be completed before the data can be considered 'stale' and once the 'stale' data is purged roll backs can not be permitted for any transaction before the purge. Eventually the automatic purging of 'stale' data will be supported, but hopefully it will be configurable to allow 'time travel' when required, and allow for a reasonable time to be able to roll back transactions.
I am not an RDBMS developer and don't claim to know how the inner workings work, but I have been using RDBMS application for many years and have worked with a number of different products. I prefer PostGreSQL over all others, but I do use others for some projects where their support or special features out way those of PostGreSQL.
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
