Stephen Frost <sfr...@snowman.net> writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Comments?
> I'm not really a huge fan of adding another GUC, to be honest. I'm more > inclined to say we treat 'max_archive_delay' as '0', and turn > max_streaming_delay into what you've described. If we fall back so far > that we have to go back to reading WALs, then we need to hurry up and > catch-up and damn the torpedos. If I thought that 0 were a generally acceptable value, I'd still be pushing the "simplify it to a boolean" agenda ;-). The problem is that that will sometimes kill standby queries even when they are quite short and doing nothing objectionable. > I'd also prefer that we only wait the > delay time once until we're fully caught up again (and have gotten > back around to waiting for new data). The delays will be measured from a receipt instant to current time, which means that the longer it takes to apply a WAL segment or WAL send chunk, the less grace period there will be. (Which is the same as what CVS HEAD does --- I'm just arguing about where we get the start time from.) I believe this does what you suggest and more. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers