From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Eliot Gable <egable+pgsql-general(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: LOCK TABLE is not allowed in a non-volatile function |
Date: | 2012-04-18 17:01:56 |
Message-ID: | 5316.1334768516@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Eliot Gable <egable+pgsql-general(at)gmail(dot)com> writes:
> While attempting to reproduce this issue in a sanitized set of tables,
> functions, and triggers, I was able to locate the issue. Apparently I did
> have another function call in there inside my summarize_individuals()
> function and that other function was marked as STABLE while trying to grab
> a SHARE lock on a table for reading purposes. However, that function will
> probably never be called by itself, and since PostgreSQL will grab the
> appropriate lock on that table anyway, I was able to just remove the lock
> statement to fix it. However, it seems to me there should be some way of
> grabbing a read-only lock on a set of tables at the top of a function
> marked STABLE simply for the purpose of enforcing the order in which tables
> are locked, regardless of which order they are queried.
Taking a lock is a side-effect, and stable functions are expected not
to have side-effects. So I don't agree that this is a bug.
However, there still might be an issue, because the CONTEXT trace that
you showed certainly seemed to point where you thought it did. So I am
wondering if there is a bug in the error-location-reporting stuff, or
if that was an artifact of having stripped out too much information.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bartosz Dmytrak | 2012-04-18 17:50:35 | Re: Feature Proposal: Constant Values in Columns or Foreign Keys |
Previous Message | Eliot Gable | 2012-04-18 16:47:43 | Re: LOCK TABLE is not allowed in a non-volatile function |