On Tue, Jul 23, 2013 at 12:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
Oh, really? Well, should we use GetActiveSnapshot() then?
That surprises me, though. I really thought the point was to cost the
index scan, and surely that will be slowed down even by entries we
can't see.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company