On Sun, Nov 27, 2016 at 9:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I pushed a patch to deal with this. I ended up simplifying the previous
> commit considerably by getting rid of the commit-multiple-deletions-per-
> transaction business. I do not think that this code will get exercised
> enough, either in the field or in testing, to justify taking a risk of
> additional bugs from that.
I think you made this considerably more fragile with those changes.
Now, if we fail to drop a temporary table, we won't do any actual
vacuuming, either. I'd be willing to bet someone will get hosed
because of that who would have been much less hosed with the previous
coding.
Whether or not burning an XID per dropped table is going to hurt
anyone is more arguable. One would like to think that only an
extraordinarily unlucky person would have many temporary tables to
drop at the very same time that they were also critically close to a
wraparound event. I wouldn't wager on this one actually biting
anyone. But I also do not think that the old code was so complex that
we couldn't have found and removed any bugs it might have had fairly
easily, so I don't agree with this change, either.
Also, I think that ripping out obviously-intentional safeguards
without discussion over a holiday weekend is not the most
collaborative approach that you could have devised.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
