On November 4, 2015 12:37:02 AM GMT+01:00, Michael Paquier <michael.paqu...@gmail.com> wrote: >On Wed, Nov 4, 2015 at 12:43 AM, Andres Freund <and...@anarazel.de> >wrote: >> On 2015-11-03 10:23:35 -0500, Robert Haas wrote: >>> On Mon, Nov 2, 2015 at 12:58 AM, Jeff Janes <jeff.ja...@gmail.com> >wrote: >>> > If a transaction holding locks aborts on an otherwise idle server, >perhaps it will take a very long time for a log-shipping standby to >realize this. But I have hard time believing that anyone who cares >about that would be using log-shipping (rather than streaming) anyway. >>> >>> I'm sure other people here understand this better than me, but I >>> wonder if it wouldn't make more sense to somehow log this data only >if >>> something material has changed in the data being logged. >> >> Phew. That doesn't seem easy to measure. I'm doubtful that it's worth >> comparing the snapshot and such, especially in the back >> branches. > >Well, I guess that's why I thought it would be more simple to check if >we are at the beginning of a segment at first sight. This has no >chance to break if anything else like that is being added in the >future as it doesn't depend on the record types, though new similar >records added on a timely manner would need a similar check. Perhaps >this could be coupled by a check on the last XLOG_SWITCH_XLOG record >instead of checkpoint activity though. > >> We could maybe add something that we only log a snapshot if XXX >> megabytes have been logged or something. But I don't know which >number >> to pick here - and if there's other write activity the price of a >> snapshot record really isn't high. > >On a completely idle system, I don't think we should log any standby >records. This is what ~9.3 does.
Are you sure? I think it'll around checkpoints, no? I thought Heikki had fixed that, but looking sound that doesn't seem to be the case. Andres --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers