On Tue, Jun 5, 2012 at 4:28 PM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Tue, Jun 5, 2012 at 10:39 PM, Magnus Hagander <mag...@hagander.net> wrote: >> On Tue, Jun 5, 2012 at 3:36 PM, Fujii Masao <masao.fu...@gmail.com> wrote: >>> On Tue, Jun 5, 2012 at 5:32 PM, Magnus Hagander <mag...@hagander.net> wrote: >>>> You also removed the "safeguard" of always sleeping at least 1 second >>>> - should we keep some level of safeguard there, even if it's not in >>>> full seconds anymore? >>>> >>>> Is the -1 sent into localTimestampDifference still relevent at all? >>> >>> No because that "safeguard" would mess up with a user who sets >>> replication_timeout to less than one second. Though I'm not sure >>> whether there is really any user who wants such too short timeout.... >> >> Right - I meant we might want to adjust the safeguad. Assuming <1 sec >> is reasonable, maybe cap it at 100ms or so? > > On second thought, the status packet interval doesn't need to be given > in milliseconds at all. As I said, which would mess up with a user who sets > replication_timeout to less than 1 sec. But since wal_receiver_status_interval > is given in seconds, we've already messed up with them even if we've > changed pg_receivexlog so that its status interval can be given in > milliseconds. > > We received no complaints about wal_receiver_status_interval so far, so > I think there is still no need to allow pg_receivexlog --statusint to be set > to less than 1 sec. Thought?
Works for me. We still need a (reworked) patch, though, right? We just move where the move between seconds and milliseconds happens? I definitely don't think we need subsecond granularity in the user facing number. Even a second is pretty short. (We do need to retain the ability to set it to 0 = off of course). -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
