Re: LockDatabaseObject vs. LockSharedObject

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: LockDatabaseObject vs. LockSharedObject
Date: 2010-08-15 19:22:06
Message-ID: 3454.1281900126@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> It seems suspicious to me that LockSharedObject() calls
> AcceptInvalidationMessges() and LockDatabaseObject() does not. Since
> the only caller of LockSharedObject() at present is
> AcquireDeletionLock(), I'm not sure there's an observable bug here at
> the moment, but then again, I'm also not sure there isn't.

ITYM the only caller of LockDatabaseObject is AcquireDeletionLock.
Given that the other logic path in AcquireDeletionLock calls
LockRelationOid, which *will* result in an AcceptInvalidationMessages
call, it does seem pretty suspicious. The type of bug that you'd
expect to have from this is that a recent DDL change on a non-relation
object might not be seen by a concurrent drop being done on that object.

I'm not sure that we have any non-relation objects that are both complex
enough and changeable enough for there to be an observable bug here,
but it seems like a risk factor going forward. It seems to me both safe
and reasonable to add an AcceptInvalidationMessages call in HEAD.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-08-15 19:41:09 Re: Cost of AtEOXact_Buffers in --enable-cassert
Previous Message Tom Lane 2010-08-15 18:58:10 DropRelFileNodeBuffers API change (was Re: [BUGS] BUG #5599: Vacuum fails due to index corruption issues)