From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(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-01 17:57:32 |
Message-ID: | 1230832652.4032.106.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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..
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2009-01-01 17:58:21 | Kerberos options requiring restart |
Previous Message | Simon Riggs | 2009-01-01 17:54:33 | Re: lazy_truncate_heap() |