William Dunn wrote: > Just had an idea and could use some feedback. If we start a transaction, > leave it idle, and use > pg_export_snapshot() to get its snapshot_id MVCC will hold all the tuples as > of that transaction's > start and any other transaction can see the state of the database as of that > time using SET > TRANSACTION SNAPSHOT snapshot_id? > > http://www.postgresql.org/docs/devel/static/functions-admin.html#FUNCTIONS-SNAPSHOT-SYNCHRONIZATION > > > I'm thinking of setting up automation to ~every half hour open a transaction > as such, close any that > have been open over an hour, and store the snapshot_id. However, I don't have > a busy system that I can > test it on. > > Of course this would cause some extra bloat because those tuples cannot get > autovacuumed until the > transaction closes but that is also the case in Oracle. Is there anything > else I am missing or a > reason that this would not be possible?
Oracle does not have that issue because modifications cannot bloat the table (the bloat is in what is called the "UNDO tablespace"). What you suggest would allow you to look at the data as they were at specific times (of the snapshots). But the price on a busy system where data are modified would be considerable; your tables might become quite bloated, and you could not use HOT updates. If you want to look into the past, wouldn't it be much more useful to have a standby server that is lagging behind? There is an option for that (recovery_min_apply_delay) from PostgreSQL 9.4 on. Yours, Laurenz Albe -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
