Robert Haas <robertmhaas@gmail.com> writes:
>> 2. snapshot-self-not-now-v1.patch changes several uses of SnapshotNow
>> to use SnapshotSelf instead. These include pgrowlocks(),
>> pgstat_heap(), and get_actual_variable_range().
> Tom proposed that we use SnapshotDirty for this case; let me just ask
> whether there are any security concerns around that. pgstattuple only
> displays aggregate information so I think that's OK, but I wonder if
> the value found in get_actual_variable_range() can leak out in EXPLAIN
> output or whatever. I can't particularly think of any reason why that
> would actually matter, but I've generally shied away from exposing
> data written by uncommitted transactions, and this would be a step in
> the other direction. Does this worry anyone else or am I being
> paranoid?
As far as get_actual_variable_range() is concerned, an MVCC snapshot
would probably be the thing to use anyway; I see no need for the planner
to be using estimates that are "more up to date" than that. pgrowlocks
and pgstat_heap() might be in a different category.
> But thinking about it a little more, I wonder why
> get_actual_variable_range() is using a snapshot at all. Presumably
> what we want there is to find the last index key, regardless of the
> visibility of the heap tuple to which it points.
No, what we ideally want is to know the current variable range that
would be seen by the query being planned.
regards, tom lane