On Tue, Jul 23, 2013 at 12:28 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers