On Tue, Jan 19, 2016 at 12:41 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > > On Mon, Jan 18, 2016 at 10:19 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Mon, Jan 18, 2016 at 10:54 AM, Michael Paquier > > <michael.paquier@gmail.com> wrote: > >> Yes, the thing is that, as mentioned at the beginning of the thread, a > >> low value of archive_timeout causes a segment to be forcibly switched > >> at the end of the timeout defined by this parameter. In combination > >> with the standby snapshot taken in bgwriter since 9.4, this is causing > >> segments to be always switched even if a system is completely idle. > >> Before that, in 9.3 and older versions, we would have a segment > >> forcibly switched on an idle system only once per checkpoint. > >> > > > > Okay, so this will fix the case where the system is idle, but what I > > am slightly worried is that it should not miss to log the standby snapshot > > due to this check when there is actually some activity in the system. > > Why is not possible to have a case such that the segment is forcibly > > switched due to reason other than checkpoint (user has requested the > > same) and the current insert LSN is at beginning of a new segment > > due to write activity? If that is possible, which to me theoretically seems > > possible, then I think bgwriter will miss to log the standby snapshot. > > Yes, with segments forcibly switched by users this check would make > the bgwriter not log in a snapshot if the last action done by server > was XLOG_SWITCH. Based on the patch I sent, the only alternative would > be to not forcedSegSwitchLSN in those code paths. Perhaps that's fine > enough for back-branches.. >
Yeah, that can work, but I think the code won't look too clean. I think
lets try out something on lines of what is suggested by Andres and
