Skip site navigation (1) Skip section navigation (2)

Re: lazy_truncate_heap()

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: lazy_truncate_heap()
Date: 2009-01-01 10:00:41
Message-ID: 495C9449.8030305@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Greg Stark wrote:
> 
> On 31 Dec 2008, at 13:21, Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
>>
>> Both of these bugs are minor, but the effect of either/both of them is
>> to cause more AccessExclusiveLocks than we might expect.
>>
>> For Hot Standby this means that many VACUUMs take AccessExclusiveLocks
>> on relations, which would potentially lead to having queries cancelled
>> for no reason at all.
> 
> Well by default it would just cause wal to pause briefly until the 
> queries with those locks finish, no?

Wait a minute. Why does an AccessExclusiveLock lead to cancelled queries 
or pausing WAL application? I thought it'd just block other queries 
trying to acquire a conflicting lock in the standby, just like holding 
an AccessExclusiveLock on the primary does. It's unrelated to the xmin 
horizon issue.

There is a noteworthy point though. In the primary, vacuum trying to 
truncate takes AccessExclusiveLock conditionally, so that it doesn't 
disturb queries accessing the table, and only truncates the table if it 
got the lock. But in standby, we have to truncate the table, and 
therefore have to acquire the lock, waiting until we get it. I guess we 
have to stop applying WAL while waiting.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2009-01-01 11:45:25
Subject: Re: TODO items for window functions
Previous:From: Heikki LinnakangasDate: 2009-01-01 09:08:28
Subject: Re: Buffer miss ratio

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group