On Sun, Nov 27, 2016 at 9:33 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
