On Thu, Feb 9, 2017 at 8:15 PM, Peter Geoghegan <pg@bowt.ie> wrote:
> BTW, aren't there cases where a PARALLEL SAFE function that needs to
> acquire locks on some arbitrary relation not referenced in the query
> can get locks on its own, which may only last as long as the parallel
> worker's lifetime? This could happen *despite* the fact that the
> author of the function may have imagined that callers could not
> release relation level locks early (i.e., by not releasing them
> directly, and so correctly following this "badly documented
> assumption").
Yes.
> It seems like the existence of PARALLEL RESTRICTED is primarily
> motivated by making stuff that definitely needs the locks to last
> until xact end being sure that that happens -- the docs say so. This
> seems wholly inconsistent with the idea that you're not supposed to
> let that happen under any circumstances. I find all this highly
> confusing. Have I missed some further subtlety that applies with
> PARALLEL RESTRICTED?
That's by no means the only thing that could cause you to mark
something PARALLEL RESTRICTED. I think you might have missed this bit
of the documentation, a few paragraphs up:
Similarly, functions must be marked <literal>PARALLEL RESTRICTED</> if they access temporary tables, client
connectionstate, cursors, prepared statements, or miscellaneous backend-local state which the system cannot
synchronizeacross workers. For example, <literal>setseed</> and <literal>random</> are parallel restricted for this
lastreason.
That stuff is the main motivation. The early lock release stuff could
come up for user-written functions, but the things listed in the
paragraph I've quoted here come up for plenty of built-in functions.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company