On Tue, May 24, 2016 at 3:54 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
