On Sat, Feb 25, 2017 at 11:41 PM, Greg Stark <st...@mit.edu> wrote: > What I'm concerned about is that silently giving "wrong" answers in > regular queries -- not even ones doing the partition key updates -- is > something the user can't really manage. They have no way to rewrite > the query to avoid the problem if some other user or part of their > system is updating partition keys. They have no way to know the > problem is even occurring.
That's a reasonable concern, but it's not like EvalPlanQual works perfectly today and never causes any application-visible inconsistencies that end up breaking things. As the documentation says: ---- Because of the above rules, it is possible for an updating command to see an inconsistent snapshot: it can see the effects of concurrent updating commands on the same rows it is trying to update, but it does not see effects of those commands on other rows in the database. This behavior makes Read Committed mode unsuitable for commands that involve complex search conditions; however, it is just right for simpler cases. ---- Maybe I've just spent too long hanging out with Kevin Grittner, but I've come to view our EvalPlanQual behavior as pretty rickety and unreliable in general. For example, consider the fact that when I spent over a year and approximately 1 gazillion email messages trying to hammer out how join pushdown was going to EPQ rechecks, we discovered that the FDW API wasn't actually handling those correctly for even for scans of single tables, hence commit 5fc4c26db5120bd90348b6ee3101fcddfdf54800. I'm not saying that time and effort wasn't well-spent, but I wonder whether it's necessary to hold partitioned tables to a higher standard than that to which the FDW interface was held for the first 4.5 years of its life. Perhaps it is good for us to do that, but I'm not 100% convinced. It seems like we decide to worry about EvalPlanQual in some cases and not in others more or less arbitrarily. -- 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