Eliot Gable <egable+pgsql-gene...@gmail.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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
