Re: Autovacuum breakage from a734fd5d1

On Mon, Nov 28, 2016 at 12:14 PM, Robert Haas <robertmhaas(at)gmail(dot)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