On Tue, Jan 19, 2016 at 12:41 PM, Michael Paquier <michael.paqu...@gmail.com>
> On Mon, Jan 18, 2016 at 10:19 PM, Amit Kapila <amit.kapil...@gmail.com>
> > On Mon, Jan 18, 2016 at 10:54 AM, Michael Paquier
> > <michael.paqu...@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
> > 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
> > 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
see how it turns out.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Reply via email to