Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> The problem with defining max_archive_delay that way is again that you
> can fall behind indefinitely.
See my response to Greg Stark --- I don't think this is really an
issue. It's certainly far less of an issue than the current situation
that query grace periods go to zero under not-at-all-extreme conditions.
> I don't understand why you want to use a different delay when you're
> restoring from archive vs. when you're streaming (what about existing
> WAL files found in pg_xlog, BTW?).
You're missing the point. I want the DBA to be able to control what
happens in those two cases. In the current implementation he has no
control over what happens while restoring from archive: it's going to
effectively act like max_archive_delay = 0 all the time. If you're of
the opinion that's good, you can set the parameter that way and be
happy. I'm of the opinion you'll soon find out it isn't so good,
because it'll kill standby queries too easily.
> I stand by my suggestion from yesterday: Let's define max_standby_delay
> as the difference between a piece of WAL becoming available in the
> standby, and applying it.
My proposal is essentially the same as yours plus allowing the DBA to
choose different max delays for the caught-up and not-caught-up cases.
Maybe everybody will end up setting the two delays the same, but I think
we don't have enough experience to decide that for them now.
regards, tom lane
