On Wed, Jun 15, 2016 at 1:59 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Kevin Grittner wrote: >> On Wed, Jun 15, 2016 at 1:50 PM, Robert Haas <robertmh...@gmail.com> wrote: >> >>> The expression index case is the one to worry about; if there is a >>> problem, that's where it is. What bothers me is that a function used >>> in an expression index could do anything at all - it can read any >>> table in the database. >> >> It *can*, but then you are lying to the database when you call it >> IMMUTABLE. Such an index can easily become corrupted through >> normal DML. Without DML the ANALYZE has no problem. So you seem >> to be concerned that if someone is lying to the database engine to >> force it accept a function as IMMUTABLE when it actually isn't, and >> then updating the referenced rows (which is very likely to render >> the index corrupted), that statistics might also become stale. > > We actually go quite some lengths to support this case, even when it's > the opinion of many that we shouldn't. For example VACUUM doesn't try > to find index entries using the values in each deleted tuple; instead we > remember the TIDs and then scan the indexes (possibly many times) to > find entries that match those TIDs -- which is much slower. Yet we do > it this way to protect the case that somebody is doing the > not-really-IMMUTABLE function. > > In other words, I don't think we consider the position you argued as > acceptable.
What are you saying is unacceptable, and what behavior would be acceptable instead? -- 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
