From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Bug in VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL |
Date: | 2016-09-06 10:30:57 |
Message-ID: | CANP8+j+w3aAv8OpNtRxhf=ZKV5fXtVuRJ+=5HJuhiWHXvHW5sA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
In vacuumlazy.c, VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL is described as
being in ms on line 85, yet it is used on line 1759 in a call to
pg_usleep, so is treated as microseconds rather than milliseconds.
As a result, the timeout during lazy_truncate_heap() is actually only
5ms long, not 5s long.
So this looks to me like a bug, patch attached, for back-patching to 9.1
vacuum_lock_wait_ms.v1,patch
Objections?
Note that VACUUM_TRUNCATE_LOCK_CHECK_INTERVAL is described as being in
ms and is actually in ms, so no change there.
I'm also wondering why we don't use lock_timeout when the user sets it?
Not a bug, but patch attached anyway.
vacuum_truncate_use_lock_timeout.v1.patch
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
vacuum_lock_wait_ms.v1.patch | application/octet-stream | 420 bytes |
vacuum_truncate_use_lock_timeout.v1.patch | application/octet-stream | 845 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2016-09-06 11:01:50 | Re: PATCH: Batch/pipelining support for libpq |
Previous Message | Craig Ringer | 2016-09-06 10:18:15 | Re: Override compile time log levels of specific messages/modules |