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

Re: SR standby hangs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <amdunstan(at)nc(dot)rr(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SR standby hangs
Date: 2011-02-22 16:34:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Tue, Feb 22, 2011 at 12:55 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> A little OT, but ISTM that the buffer pin mechanism by its nature is
>> prone to lock upgrade hazards.

> Except that pins don't block exclusive locks so there's no deadlock risk.

> The oddity here is on Vacuums super-exclusive "lock" which is the real
> equivalent of an "exclusive lock". However there's the added bonus
> that there can only be one vacuum on a table at a time. That makes it
> safe

We have seen deadlocks arising from this type of scenario:

	autovac has vacuum lock on table X
	autovac blocks waiting for cleanup lock on buffer B in X
	process P has pin on B due to a suspended query (eg cursor)
	P tries to get exclusive lock on X, is blocked by autovac's lock

The heavyweight-lock manager fails to recognize deadlock because it
doesn't know about the buffer-level LWLock.

> It might be interesting to have autovacuum skip a block it finds
> pinned for too long.

+1, although as somebody pointed out nearby, this will only be legal if
it's not a vacuum-to-prevent-wraparound situation.

> Incidentally, even if we allowed multiple vacuum processes per table I
> think it could be coded to be safe as long as each vacuum only needs
> to acquire the super exclusive lock on a single block at a time and
> doesn't try to acquire other locks while holding it.

IIRC, it's cleaning the indexes that is problematic.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2011-02-22 16:40:25
Subject: Re: pg_resetxlog display bogosity
Previous:From: Robert HaasDate: 2011-02-22 16:33:25
Subject: Re: PostgreSQL FDW update

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