On 2017-11-05 22:43:34 -0500, Tom Lane wrote: > > IIUC the problem here is that even though a lock is already > > held by the main backend an independent locker's request will prevent > > the on-demand lock by the dump worker from being granted. It seems to > > me the correct fix here would be to somehow avoid the fairness logic in > > the parallel dump case - although I don't quite know how to best do so. > > I wonder if we couldn't somehow repurpose the work that was done for > parallel workers' locks. Lots of security-type issues to be handled > if we're to open that up to clients, but maybe it's solvable. For > instance, maybe only allowing it to clients sharing the same snapshot > would help.
Yea, I'd been wondering the same. I'm slightly worried that somehow tying multiple clients into parallel mode would cause a bunch of problems - that's not really the purpose of the code and a number of its assumptions aren't quite right for that. I'm not sure it really buys us much in contrast to just allowing a locker to specify that it's allowed to jump the lock queue for an ASL if it has 'backup' rights or such. Or actually, just allow it as a general option to LOCK, there's plenty other operational cases where the current "fair" behaviour is really annoying, e.g. when executing operational DDL/DML and such. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
