Christopher Browne <cbbrowne@libertyrms.info> writes:
> I would, given an ideal world, prefer to be able to have a connection
> or two live during this to let me monitor the DB and even get an early
> peek at the data.
On that note, how hard would it be to implement a read-dirty mode in postgres?
This would be useful for few things, the only thing I can think of are
progress indicators for long-running updates/inserts.
It seems like it falls naturally out of the MVCC algorithm, simply have it set
the transaction id of the current transaction to be a magic value that
compares greater than any transaction id. So all uncommitted transactions are
seen as having been committed in the past.
I don't see any real need for updates or inserts, but reasonable semantics for
them also fall out of MVCC. Any updates or inserts should be seen as being
committed infinitely far in the future. So they can only be seen by other
read-dirty transactions.
The main use for this that I see are doing select count(*) on tables being
imported or inserted into. Or perhaps being able to peek at records being
updated by another session in a long-running job.
If nothing else it'll save the load on the mailing list every time people ask
how to calculate how much longer their data load is going to take based on the
size of the files in the postgres data directory.
I'm sure I'm skipping a few steps. What I said doesn't quite make sense on its
own. I think I'm missing some key elements of the postgres MVCC system.
--
greg