Robert Haas <robertmh...@gmail.com> writes: > On Mon, Jul 29, 2019 at 9:48 PM Tom Lane <t...@sss.pgh.pa.us> wrote: >> I believe the only accessible route to taking any sort of new lock >> in a parallel worker is catalog lookups causing AccessShareLock on >> a catalog.
> Can't the worker just query a previously-untouched table, maybe by > constructing a string and then using EXECUTE to execute it? Hm, yeah, looks like you could get a new AccessShareLock that way too. But not any exclusive lock. I also looked into whether one could use SELECT FOR UPDATE/SHARE to get stronger locks at a tuple level, but that's been blocked off as well. You guys really did a pretty good job of locking that down. After thinking about this for awhile, though, I believe it might be reasonable to just remove PreventAdvisoryLocksInParallelMode() altogether. The "parallel unsafe" markings on the advisory-lock functions seem like adequate protection against somebody running them in a parallel worker. If you defeat that by calling them from a mislabeled-parallel-safe wrapper (as the proposed test case does), then any negative consequences are on your own head. AFAICT the only actual negative consequence is that the locks disappear the moment the parallel worker exits, so we'd not be opening any large holes even to people who rip off the safety cover. (BTW, why aren't these functions just "parallel restricted"?) regards, tom lane