On Mon, Nov 28, 2016 at 12:14 PM, Robert Haas <robertmh...@gmail.com> wrote: > 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.
[ ... Reading the actual change ...] Right. This is missing a PG_TRY/CATCH block, the previous patch has been designed to be non-disruptive with the next operations of autovacuum. So HEAD is now far more invasive in the way of doing things. > 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. Don't we need to worry about burning too many transaction XIDs for a wraparound autovacuum? I am aware of the fact that this is really a corner-case but burning potentially thousands of them to drop that much orphaned object does not sound really appealling to me. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
