Re: HS locking broken in HEAD

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: HS locking broken in HEAD
Date: 2013-01-17 23:22:26
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2013-01-17 23:56:16 +0100, Andres Freund wrote:
> On 2013-01-17 22:46:21 +0100, Andres Freund wrote:
> > Note the conflicting locks held on relation foo by 28048 and 28068.
> >
> > I don't immediately know which patch to blame here? Looks a bit like
> > broken fastpath locking, but I don't immediately see anything in
> > c00dc337b87 that should cause this?
> Rather scarily this got broken in
> 96cc18eef6489cccefe351baa193f32f12018551. Yes, nearly half a year ago,
> including in 9.2.1+. How the heck could this go unnoticed so long?

That only made the bug more visible - the real bug is somewhere
else. Which makes it even scarrier, the bug was in in the fast path
locking patch from the start...

It assumes conflicting fast path locks can only ever be in the same
database as the the backend transfering the locks to itself. But thats
obviously not true for the startup process which is in no specific
I think it might also be a dangerous assumption for shared objects?

A patch minimally addressing the is attached, but it only addresses part
of the problem.


Andres Freund

Andres Freund
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
partially-fix-fast-path-locking-conflict-with-recovery.patch text/x-patch 943 bytes

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2013-01-17 23:24:31 Re: Re: Slave enters in recovery and promotes when WAL stream with master is cut + delay master/slave
Previous Message Tom Lane 2013-01-17 23:22:10 Re: Event Triggers: adding information