Re: Add cassert-only checks against unlocked use of relations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Kevin Grittner <kgrittn(at)ymail(dot)com>
Subject: Re: Add cassert-only checks against unlocked use of relations
Date: 2013-11-05 21:45:49
Message-ID: 31989.1383687949@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-11-05 16:25:53 -0500, Tom Lane wrote:
>> If we're sufficiently worried by this type of bug, ISTM we'd be better off
>> just disallowing heap_open(NoLock). At the time we invented that, every
>> lock request went to shared memory; but now that we have the local lock
>> table, re-locking just requires a local hash lookup followed by
>> incrementing a local counter. That's probably pretty cheap --- certainly
>> a lot cheaper than what you've got here.

> Hm. That only works though if we're using the same lockmode as before -
> often enough the *_open(NoLock) checks would use a weaker locklevel than
> the previous lock. So I think the cost of doing so would probably be
> noticeable.

If you're not using the same lockmode as before, it's probably a bug anyway.
As I said already, the entire NoLock coding technique is dependent on
having a very clear idea of which previous lock-taking you're riding
on the coattails of. Why wouldn't you duplicate that lock level,
if we say you can't use NoLock anymore?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2013-11-05 21:48:12 Re: missing locking in at least INSERT INTO view WITH CHECK
Previous Message Andres Freund 2013-11-05 21:35:41 Re: Add cassert-only checks against unlocked use of relations