On Tue, May 24, 2016 at 3:54 PM, Andres Freund <andres@anarazel.de> wrote:
> what about e.g. concurrent index builds? E.g. IndexBuildHeapRangeScan() doesn't
> seem to contain any checks against outdated blocks
Why would it? We're talking about blocks where there were dead
tuples, with the transaction which updated or deleted the tuples
being complete, where those dead tuples were vacuumed away. These
should not appear in the index, should they?
> and that's certainly not ok?
Why not?
> It appears that concurrent index builds are currently broken
> from a quick skim?
Either you don't understand this feature very well, or I don't
understand concurrent index build very well. I thought we burned a
lot of time going through the index an extra time just to get rid
of dead tuples -- why would it be a problem not to add them in the
first place?
>>> Is there anything preventing this from becoming a problem?
>>
>> The fundamental approach that the error can only appear on
>> user-facing scans, not internal reads and positioning.
>
>> Unless there is some code path that uses a scan where the snapshot
>> age is checked, this cannot be a problem. I don't see any such
>> path, but if you do, please let me know, and I'll fix things.
>
> That scares me. Not throwing an error, and not being broken are entirely
> different things.
Absolutely, but let's not start pointing at random chunks of code
and asking why an error isn't thrown there without showing that you
get bad results otherwise, or at least some plausible argument why
you might.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company