On Fri, Jan 21, 2011 at 8:05 AM, Nicolas Barbier <nicolas.barb...@gmail.com> wrote: > 2011/1/21 Anssi Kääriäinen <anssi.kaariai...@thl.fi>: > >> Sorry for bothering all of you, but I just don't get this. What if T2 rolls >> back instead of committing? Then the snapshot of T3 would have been valid, >> right? Now, for the snapshot of T3 it doesn't matter if T2 commits or if it >> doesn't, because it can't see the changes of T2 in any case. Thus, it would >> seem that the snapshot is valid. On the other hand I can't see anything >> wrong in the logic in your post. What am I missing? I am feeling stupid... >> >> At least for dumps I don't see how T2 can matter (assuming T3 is the >> pg_dump's snapshot). Because if you reload from the dump, T2 never happened >> in that dump. In the reloaded database it just did not exist at all. > > This has been discussed before; in [1] I summarized: > > "IOW, one could say that the backup is consistent only if it were > never compared against the system as it continued running after the > dump took place."
But that's a pretty fair way to look at it, isn't it? I mean, I guess it's a question of what you plan to use that backup for, but if it's disaster recovery, everything that happened after the dump is gone, so no such comparison will occur. And that's probably the most common reason for taking a dump. It occurs to me that focusing on how this is going to work on Hot Standby might be looking at the question too narrowly. The general issue is - does this technique generalize to a distributed computing environment, with distributed transactions across multiple PostgreSQL databases? For example, what if the control record in Kevin's example is stored in another database, or on another server. Or what if some tables are replicated via Slony? I realize this is all outside the scope of the patch, but that's exactly the point: making this stuff work across multiple databases (even if they are replicas of each other) is much more complex than getting it to work on just one machine. Even if we could agree on how to do it, coming up with some hack that can only ever possibly work in the Hot Standby case might not be the best thing to do. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers