On 8/26/19 2:55 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> On 8/21/19 4:16 PM, Tom Lane wrote:
>>> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>>>> Still, if we simply added the skew to the snapshot time that might be
>>>> enough to achieve what you want. That would be a one line change, I think.
>>> +1
>> Done. It's only happening prospectively, so we'll need to wait a few
>> days to see it flow through.
> Hm, doesn't seem to have done the trick. The current dashboard page shows
> (in the v12 branch)
>
> mule ... 01:17 ago OK [97205d0] Config
> loach ... 01:32 ago OK [97205d0] Config
> dangomushi ... 02:11 ago OK [97205d0] Config
> bowerbird ... 02:23 ago scriptsCheck [97205d0] Details
> snapper ... 02:48 ago OK [63fc3b1] Config
> caiman ... 03:04 ago OK [97205d0] Config
> nightjar ... 03:17 ago recoveryCheck [97205d0] Details
> chub ... 03:29 ago OK [97205d0] Config
> clam ... 03:34 ago OK [97205d0] Config
> demoiselle ... 03:45 ago OK [97205d0] Config
>
> snapper is clearly out of line here: the commit it claims
> to have fetched 2:48 ago was obsoleted around seven hours ago.
>
> (Snapper is one of the machines that is typically inconsistent
> in this way. I've been assuming that's because its system clock
> is a few hours off ... but maybe there's something else going on?)
>
>
I think this is the problem:
'scmrepo' => '/home/pgbf/pgmirror.git',
Probably this isn't updated often enough. It probably has little to do with the clock settings.
This is the kind of old-fashioned way of doing things. These days "git_keep_mirror => 1" along with the community repo
asthe base would avoid these problems.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
