Eliot Gable <egable+pgsql-general@xxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
