On Wed, Oct 19, 2016 at 09:00:06AM -0400, Robert Haas wrote:
> On Wed, Oct 19, 2016 at 8:47 AM, Bruce Momjian <br...@momjian.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 <j...@agliodbs.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

  Bruce Momjian  <br...@momjian.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 +

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to