Re: getting rid of SnapshotNow - Mailing list pgsql-hackers

From Robert Haas
Subject Re: getting rid of SnapshotNow
Date
Msg-id CA+TgmoYOtRKLmbzuSn_1SFchrFsL9dq9MNgWooC_7brz83+P6w@mail.gmail.com
Whole thread Raw
In response to Re: getting rid of SnapshotNow  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: getting rid of SnapshotNow  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Fri, Jul 19, 2013 at 12:51 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Robert Haas escribió:
>> On Fri, Jul 19, 2013 at 12:29 PM, Alvaro Herrera
>> <alvherre@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


pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: FKey not enforced resulting in broken Dump/Reload
Next
From: Robert Haas
Date:
Subject: Re: FKey not enforced resulting in broken Dump/Reload