Re: Proposal: Log inability to lock pages during vacuum

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Log inability to lock pages during vacuum
Date: 2014-12-17 16:20:49
Message-ID: 5491AD61.3020406@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/01/2014 08:55 PM, Jim Nasby wrote:
> On 12/1/14, 11:57 AM, Andres Freund wrote:
>> On 2014-11-30 20:46:51 -0600, Jim Nasby wrote:
>>> On 11/10/14, 7:52 PM, Tom Lane wrote:
>>>> On the whole, I'm +1 for just logging the events and seeing what we learn
>>>> that way. That seems like an appropriate amount of effort for finding out
>>>> whether there is really an issue.
>>>
>>> Attached is a patch that does this.
>>
>> Unless somebody protests I plan to push this soon. I'll change two
>> things:
>>
>> * Always use the same message, independent of scan_all. For one Jim's
>> version would be untranslatable, for another it's not actually
>> correct. In most cases we'll *not* wait, even if scan_all is
>> true as we'll often just balk after !lazy_check_needs_freeze().
>
> Good point.
>
>> * Change the new bit in the errdetail. "could not acquire cleanup lock"
>> sounds too much like an error to me. "skipped %u pinned pages" maybe?
>
> Seems reasonable.

Well, that's not always true either; when freezing, it doesn't skip the
pinned pages, it waits for them.

How about the attached (I also edited the comments a bit)? It looks like
this:

postgres=# vacuum verbose foo;
INFO: vacuuming "public.foo"
INFO: "foo": found 0 removable, 0 nonremovable row versions in 0 out of
7256 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
1 pages were pinned.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "foo": stopping truncate due to conflicting lock request
INFO: vacuuming "pg_toast.pg_toast_16384"
INFO: index "pg_toast_16384_index" now contains 0 row versions in 1 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.

and for autovacuum log:

LOG: automatic vacuum of table "postgres.public.foo": index scans: 0
pages: 0 removed, 7256 remain, 0 pinned
tuples: 79415 removed, 513156 remain, 0 are dead but not yet removable
buffer usage: 14532 hits, 6 misses, 6241 dirtied
avg read rate: 0.003 MB/s, avg write rate: 3.413 MB/s
system usage: CPU 0.00s/0.30u sec elapsed 14.28 sec

I.e. this just says how many pages were pinned, without saying what was
done about them. That's not very meaningful to an average DBA, but
that's true for many of the numbers printed in vacuum verbose.

- Heikki

Attachment Content-Type Size
log-cleanup-lock-acquisition-failures-in-vacuum-2.patch text/x-diff 2.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2014-12-17 16:34:25 Re: [alvherre@2ndquadrant.com: Re: no test programs in contrib]
Previous Message Teodor Sigaev 2014-12-17 15:56:48 Re: speedup tidbitmap patch: cache page