Re: Lock problem with autovacuum truncating heap

On Sun, Mar 27, 2011 at 9:41 PM, Jan Wieck <JanWieck(at)yahoo(dot)com> wrote:
> On 3/27/2011 6:21 PM, Robert Haas wrote:
>>
>> On Sun, Mar 27, 2011 at 3:25 PM, Jan Wieck<JanWieck(at)yahoo(dot)com>  wrote:
>>>
>>>  Since we are talking about stable releases, I think just releasing and
>>>  reacquiring the exclusive lock is enough. We can then try to further
>>> improve
>>>  things for future releases.
>>
>> That seems unsafe - things can change under you while you don't hold the
>> lock...
>
> The only change relevant in this case would be some concurrent client
> extending the relation while we don't hold the lock. A call to
> RelationGetNumberOfBlocks() after reacquiring the lock will tell. Safety
> reestablished.

I thought that the risk was that someone might write tuples into the
blocks that we're thinking of truncating.

>> I kind of like the idea of committing the transaction and then
>> beginning a new one just to do the truncation.  Given the way the
>> deadlock detector treats autovacuum, the current coding seems quite
>> risky.
>
> I don't like a 1,000 ms hiccup in my system, regardless of how many
> transaction hoops you make it go through.

I can't argue with that.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company