Re: Signaling of waiting for a cleanup lock?

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Signaling of waiting for a cleanup lock?
Date: 2014-04-14 17:01:42
Message-ID: 20140414170142.GG5822@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

> In an ideal world, when we needed to wait for a cleanup lock, we'd cause
> the lock manager to set up pre-granted sharable page locks for all the
> processes currently holding buffer pins, and then wait for an exclusive
> page lock. The current hack of signaling when you're the last one off the
> page would be replaced by releasing your lock (if it exists) when you drop
> your own pin. I'm not sure it's really worth the trouble to try to do
> this, but it would solve the visibility problem; and it might allow us to
> be a bit smarter about the priority of a cleanup lock request versus
> incoming regular pin requests.

AFAIU this would represent a behavioral change: right now, vacuum waits
until everybody is gone, and new pinners might arrive while vacuum is
waiting. With this scheme, new pinners would have to wait behind
vacuum. Maybe this change alone is enough to avoid vacuum blocking for
long periods waiting for cleanup lock.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-04-14 17:06:21 Re: Signaling of waiting for a cleanup lock?
Previous Message Robert Haas 2014-04-14 16:55:35 Re: Including replication slot data in base backups