Re: Potential GIN vacuum bug

On Mon, Aug 31, 2015 at 12:10 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:

> On Sun, Aug 30, 2015 at 3:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
>> > On Sun, Aug 30, 2015 at 11:11 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
> > But we would still have to deal with the
>> > fact that unconditional acquire attempt by the backends will cause a
>> vacuum
>> > to cancel itself, which is undesirable.
>>
>> Good point.
>>
>> > If we define a new namespace for
>> > this lock (like the relation extension lock has its own namespace) then
>> > perhaps the cancellation code could be made to not cancel on that
>> > condition. But that too seems like a lot of work to backpatch.
>>
>> We could possibly teach the autocancel logic to distinguish this lock type
>> from others without using a new namespace. That seems a bit klugy, but
>> maybe better than adding a new namespace. (For example, there are
>> probably only a couple of modes in which we take page-level locks at
>> present. Choosing a currently unused, but self-exclusive, mode for taking
>> such a lock might serve.)
>>
>
> Like the attached? (The conditional variant for user backends was
> unceremoniously yanked out.)
>

A problem here is that now we have the user backends waiting on vacuum to
do the clean up, but vacuum is using throttled IO and so taking its sweet
time at it. Under the old code, the user backend could pass up the vacuum
while it was sleeping.

Maybe we could have the vacuum detect when someone is waiting on it, and
temporarily suspend throttling and just run at full speed. I don't believe
there is any precedence for that, but I do think there are other places
where such a technique could be useful. That is kind of a scary change to
backpatch.

I am running out of ideas.

Cheers,

Jeff