| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Mikael Kjellström <mikael(dot)kjellstrom(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Weird failure in explain.out with OpenBSD |
| Date: | 2021-11-11 03:35:05 |
| Message-ID: | 20211111033505.mmfqif4x5errbuss@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2021-11-11 14:15:33 +1300, Thomas Munro wrote:
> Some starter questions for Mikael would be: could you please check
> which clock source it's using?, is it under a hypervisor, and if so
> which?, what is the CPU model?, what are other kernels choosing when
> running as guests on the same hypervisor (if applicable)? Did
> anything interesting happen on either the guest or host operating
> system (if not bare metal) some time around 2021-11-10 21:59 CET?
> I'm no expert on this stuff but something tells me that a 124ms leap
> needs a different explanation than the sub-µs difference reported
> earlier...
One quite conceivable way could be a VM migration. Which quite a few hosters
can do behind ones back, to reduce downtimes in case of hardware maintenance
etc. If openbsd is using the TSC, and something in the stack isn't quite
dealing correctly with the necessary tsc offset / speed correction values
you'd expect to see something like this.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2021-11-11 03:41:53 | Re: Parallel vacuum workers prevent the oldest xmin from advancing |
| Previous Message | Masahiko Sawada | 2021-11-11 03:22:42 | Re: Parallel vacuum workers prevent the oldest xmin from advancing |