On 2021-11-11 02:15, Thomas Munro wrote:
I dunno. Clocks on virtualised systems and even metal seem to be a
minefield of quirks and heuristics. Some discussion, may or may not
be relevant:
https://marc.info/?l=openbsd-tech&m=161657532610882&w=2
Just for fun I compiled and ran the test progr
On 2021-11-11 04:35, Andres Freund wrote:
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 t
On 2021-11-11 02:15, Thomas Munro wrote:
On Thu, Nov 11, 2021 at 1:15 PM Michael Paquier wrote:
morepork uses 6.9 now, but it has been recently upgraded from 5.4 or
a version close to that, right? I am wondering if 7.0 may help
regarding this issue. Postgres is not wrong here.
I dunno. C
On 2021-11-11 01:15, Michael Paquier wrote:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=morepork&dt=2021-11-10%2020%3A51%3A32
Yeah, I have noticed this failure yesterday.
morepork uses 6.9 now, but it has been recently upgraded from 5.4 or
a version close to that, right? I am
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 hy
On Thu, Nov 11, 2021 at 1:15 PM Michael Paquier wrote:
> morepork uses 6.9 now, but it has been recently upgraded from 5.4 or
> a version close to that, right? I am wondering if 7.0 may help
> regarding this issue. Postgres is not wrong here.
I dunno. Clocks on virtualised systems and even met
On Thu, Nov 11, 2021 at 10:23:06AM +1300, Thomas Munro wrote:
> If I'm reading this right, it might be further evidence of
> CLOCK_MONOTONIC going backwards on OpenBSD, this time by quite a lot
> (the regular expression doesn't tolerate a leading minus sign, so the
> test failed):
>
> https://buil
On Wed, Dec 30, 2020 at 8:17 PM Michael Paquier wrote:
> On Tue, Dec 29, 2020 at 04:16:06PM -0500, Tom Lane wrote:
> > Hmph, no, a look at explain.c shows that the "Execution Time" is just
> > based on the difference of INSTR_TIME_SET_CURRENT measurements taken
> > within the current process. It'
On Tue, Dec 29, 2020 at 04:16:06PM -0500, Tom Lane wrote:
> Hmph, no, a look at explain.c shows that the "Execution Time" is just
> based on the difference of INSTR_TIME_SET_CURRENT measurements taken
> within the current process. It's difficult to conclude anything except
> that the clock went ba
I wrote:
> ... so my guess is that something messed up in transmitting or combining a
> parallel worker's execution time.
Hmph, no, a look at explain.c shows that the "Execution Time" is just
based on the difference of INSTR_TIME_SET_CURRENT measurements taken
within the current process. It's dif
Michael Paquier writes:
> Buildfarm member gombessa just had an interesting failure:
> - Execution Time: N.N ms
> + Execution Time: -N.N ms
> Not sure what to think about that, as this implies the calculation of
> a negative execution time.
Yeah, I saw that. I notice that gombessa uses
Hi all,
Buildfarm member gombessa just had an interesting failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gombessa&dt=2020-12-29%2000%3A16%3A49
Seq Scan on int8_tbl i8 (cost=N.N..N.N rows=N width=N) (actual
time=N.N..N.N rows=N loops=N)
Planning Time: N.N ms
- Execution Tim
12 matches
Mail list logo
