From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: getting rid of SnapshotNow |
Date: | 2013-07-23 18:08:29 |
Message-ID: | CA+TgmobKTMoRzaJ5iAUiHhta-qvi9eYgqC_fvs4m7JznFfhh5g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-odbc |
On Tue, Jul 23, 2013 at 12:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-07-23 18:16:20 | Re: new "row-level lock" error messages |
Previous Message | Greg Smith | 2013-07-23 17:16:52 | Re: [v9.4] row level security |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-07-23 18:24:32 | Re: getting rid of SnapshotNow |
Previous Message | Tom Lane | 2013-07-23 16:28:34 | Re: getting rid of SnapshotNow |