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

Re: lazy_truncate_heap()

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: lazy_truncate_heap()
Date: 2009-01-04 11:01:56
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
Simon Riggs wrote:
> On Thu, 2009-01-01 at 12:00 +0200, Heikki Linnakangas wrote:
>> 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.
> Yes, it is unrelated to the xmin horizon issue. There are two reasons
> for delaying WAL apply:
> * locks
> * xmin horizon
> When a lock is acquired on the primary it almost always precedes an
> action which cannot occur concurrently. For example, if VACUUM did
> truncate a table then queries could get errors because parts of their
> table disappear from under them. Others are drop table etc..

Have you implemented the query cancellation mechanism for that scenario 
too? (I'm cool either way, just curious..)

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2009-01-04 12:48:03
Subject: Re: lazy_truncate_heap()
Previous:From: Heikki LinnakangasDate: 2009-01-04 10:49:07
Subject: Re: pg_stats queries versus per-database encodings

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