Re: Remove vacuum_defer_cleanup_age

On Wed, Oct 19, 2016 at 09:00:06AM -0400, Robert Haas wrote:
> On Wed, Oct 19, 2016 at 8:47 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > On Wed, Oct 19, 2016 at 08:33:20AM -0400, Robert Haas wrote:
> >> On Tue, Oct 18, 2016 at 4:33 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> >> > Based on that argument, we would never be able to remove any
> >> > configuration parameter ever.
> >>
> >> Well... no. Based on that argument, we should only remove
> >> configuration parameters if we're fairly certain that they are not
> >> useful any more, which will be rare, but is not never. I agree that
> >> *if* vacuum_defer_cleanup_age is no longer useful, it should be
> >> removed. I'm just not convinced that it's truly obsolete, and you
> >> haven't really offered much of an argument for that proposition. It
> >> does something sufficiently different from hot_standby_feedback that
> >> I'm not sure it's accurate to say that one can substitute for the
> >> other, and indeed, I see Andres has already suggested some scenarios
> >> where it could still be useful.
> >>
> >> Actually, I think vacuum_defer_cleanup_age is, and always has been, an
> >> ugly hack. But for some people it may be the ugly hack that is
> >> letting them continue to use PostgreSQL.
> >
> > I see vacuum_defer_cleanup_age as old_snapshot_threshold for standby
> > servers --- it cancels transactions rather than delaying cleanup.
>
> I think it's the opposite, isn't it? vacuum_defer_cleanup_age
> prevents cancellations.

Uh, vacuum_defer_cleanup_age sets an upper limit on how long, in terms
of xids, that a standby query can run before cancel, like
old_snapshot_threshold, no? After that, we can cancel standby queries.
I see hot_standby_feedback as our current behavior on the master where
we never cancel standby queries.

To me, hot_standby_feedback extends no-cleanup-no-cancel from the
standby to the master, while vacuum_defer_cleanup_age behaves like
old_snapshot_threshold in that it causes cancel for long-running
queries.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +