From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Odd, intermittent failure in contrib/pageinspect |
Date: | 2021-01-19 05:15:46 |
Message-ID: | YAZrAq+w50tAkpTt@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 18, 2021 at 05:47:40PM -0500, Tom Lane wrote:
> Right, then we don't need any strange theories about autovacuum,
> just bad timing luck. whelk does seem pretty slow, so it's not
> much of a stretch to imagine that it's more susceptible to this
> corner case than faster machines.
>
> So, do we have any other tests that are invoking a manual vacuum
> and assuming it won't skip any pages? By this theory, they'd
> all be failures waiting to happen.
That looks possible by looking at the code around lazy_scan_heap(),
but that's narrow.
check_heap.sql and heap_surgery.sql have one VACUUM FREEZE each and it
seems to me that we had better be sure that no pages are skipped for
their cases?
The duplicated query result looks to be an oversight from 58b4cb3 when
the thing got rewritten, so it can just go away. Good catch.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | James Hilliard | 2021-01-19 05:20:19 | Re: [PATCH 1/1] Initial mach based shared memory support. |
Previous Message | Amit Kapila | 2021-01-19 05:15:26 | Re: Parallel INSERT (INTO ... SELECT ...) |