On Fri, Jul 19, 2013 at 12:51 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Robert Haas escribió: >> On Fri, Jul 19, 2013 at 12:29 PM, Alvaro Herrera >> <alvhe...@2ndquadrant.com> wrote: > >> > I think seeing otherwise invisible rows is useful in pgrowlocks. It >> > helps observe the effects on tuples written by concurrent transactions >> > during experimentation. But then, maybe this functionality belongs in >> > pageinspect instead. >> >> It does seem like it should be useful, at least as an option. But I >> feel like changing that ought to be separate from getting rid of >> SnapshotNow. It seems like too big of a behavior change to pass off >> as a harmless tweak. > > Agreed.
So any change we make to pgrowlocks is going to have some behavior consequences. 1. If we use SnapshotSelf, then nobody will notice the difference unless this is used as part of a query that locks or modifies tuples in the table being examined. But in that case you might see the results of the current query. Thus, I think this is the smallest possible behavior change, but Tom doesn't like SnapshotSelf any more than he likes SnapshotNow. 2. If we use SnapshotDirty, then the difference is probably noticeable, because you'll see the results of concurrent, uncommitted transactions. Maybe useful, but probably shouldn't be the new default. 3. If we use a fresh MVCC snapshot, then when you scan a table you'll see the state of play as of the beginning of your scan rather than the state of play as of when your scan reaches the target page. This might be noticeable on a large table. However, it might also be thought an improvement. 4. If we use GetActiveSnapshot, all the comments about about a fresh MVCC snapshot still apply. However, the snapshot in question could be even more stale, especially in repeatable read or serializable mode. However, this might be thought a more consistent behavior than what we have now. And I'm guessing that this function is typically run as its own transaction, so in practice this doesn't seem much different from an MVCC snapshot, only cheaper. At the moment, I dislike #2 and slightly prefer #4 to #3. -- 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
