Michael Paquier writes:
> On Tue, Jan 19, 2021 at 05:03:49PM -0500, Tom Lane wrote:
>> In short I propose the attached patch, which also gets rid of
>> that duplicate query.
> Agreed, +1.
Pushed, thanks for looking at it.
regards, tom lane
On Tue, Jan 19, 2021 at 05:03:49PM -0500, Tom Lane wrote:
> It looks to me like heap_surgery ought to be okay, because it's operating
> on a temp table; if there are any page access conflicts on that, we've
> got BIG trouble ;-)
Bah, of course. I managed to miss this part.
> Poking around, I fou
Andres Freund writes:
> I think you don't event need checkpointer to be involved, normal buffer
> replacement would do the trick. We briefly pin the page in BufferAlloc()
> even if the page is clean. Longer when it's dirty, of course.
True, but it seems unlikely that the pages in question here wo
Hi,
On 2021-01-18 19:40:05 -0300, Alvaro Herrera wrote:
> > [ thinks for a bit... ] Does the checkpointer pin pages it's writing
> > out? I guess it'd have to ...
>
> It does, per SyncOneBuffer(), called from BufferSync(), called from
> CheckPointBuffers().
I think you don't event need checkpo
Michael Paquier writes:
> On Mon, Jan 18, 2021 at 05:47:40PM -0500, Tom Lane wrote:
>> 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.
> check_heap.sql and heap_surgery.sql have
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
Alvaro Herrera writes:
> On 2021-Jan-18, Tom Lane wrote:
>> [ thinks for a bit... ] Does the checkpointer pin pages it's writing
>> out? I guess it'd have to ...
> It does, per SyncOneBuffer(), called from BufferSync(), called from
> CheckPointBuffers().
Right, then we don't need any strange t
On 2021-Jan-18, Tom Lane wrote:
> Right. If that's the explanation, then adding DISABLE_PAGE_SKIPPING
> to the test's VACUUM options should fix it. However, to believe that
> theory you have to have some reason to think that some other process
> might have the page pinned. What would that be?
Alvaro Herrera writes:
> On 2021-Jan-18, Tom Lane wrote:
>> Searching the buildfarm logs turned up exactly one previous occurrence,
>> also on whelk [2]. So I'm not sure what to make of it. Could the
>> immediately preceding VACUUM FREEZE command have silently skipped this
>> page for some reaso
On 2021-Jan-18, Tom Lane wrote:
> Searching the buildfarm logs turned up exactly one previous occurrence,
> also on whelk [2]. So I'm not sure what to make of it. Could the
> immediately preceding VACUUM FREEZE command have silently skipped this
> page for some reason? That'd be a bug I should
whelk failed today [1] with this surprising symptom:
--- snip ---
diff -w -U3
C:/buildfarm/buildenv/HEAD/pgsql.build/contrib/pageinspect/expected/page.out
C:/buildfarm/buildenv/HEAD/pgsql.build/contrib/pageinspect/results/page.out
---
C:/buildfarm/buildenv/HEAD/pgsql.build/contrib/pageinspect/e
11 matches
Mail list logo
