Re: Failed to request an autovacuum work-item in silence

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Failed to request an autovacuum work-item in silence
Date: 2018-03-01 19:18:02
Message-ID: 20180301191802.ckzpza3u7kko6546@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Masahiko Sawada wrote:

> While reading the code, I realized that the requesting an autovacuum
> work-item could fail in silence if work-item array is full. So the
> users cannot realize that work-item is never performed.
> AutoVacuumRequestWork() seems to behave so from the initial
> implementation but is there any reason of such behavior? It seems to
> me that it can be a problem even now that there is only one kind of
> work-item. Attached patch for fixing it.

Hmm, yeah.

I think it would be better to return false to caller, and have them
report the failure. Then they're in a better position to place an
accurate log message -- for instance indicating the relation name rather
than just OID, and specify work item type rather than some weird
integer. (I think the ereport() should definitely be *outside* the
locked section, in any case.)

I'm inclined to change the API of AutoVacuumRequestWork even in branch
10. Since this stuff is not nicely extensible (c.f. perform_work_item),
it doesn't seem likely that any outside code is calling it yet. Once we
have hooks to register worker functions and stuff, it'll become more of
a problem.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2018-03-01 19:19:33 Re: "failed to find parent tuple for heap-only tuple" error as an ERRCODE_DATA_CORRUPTION ereport()
Previous Message Andres Freund 2018-03-01 19:17:30 Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager