On Thu, Feb 9, 2017 at 8:15 PM, Peter Geoghegan <p...@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 connection state, cursors, prepared statements, or miscellaneous backend-local state which the system cannot synchronize across workers. For example, <literal>setseed</> and <literal>random</> are parallel restricted for this last reason. 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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers