On Thu, Feb 9, 2017 at 2:47 PM, Peter Geoghegan <p...@bowt.ie> wrote: >> which isn't an issue here, but reinforces my point about the (badly >> documented) assumption that we don't release locks on user relations >> early. > > You are right about the substantive issue, I assume, but I have a hard > time agreeing with the idea that it's even badly documented when there > are at least 10 counter-examples of blithely doing this. In any case, > I find it very confusing when you talk about things as established > practice/coding standards when they're very clearly not consistently > adhered to at all. You should at least say "let's not make a bad > situation any worse", or something, so that I don't need to spend 10 > minutes pulling my hair out.
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"). 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? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
