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 queries. -- 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: http://www.postgresql.org/mailpref/pgsql-hackers
