<p dir="ltr">I agree. It is an ugly hack. <p dir="ltr">But to me, the reduced window for failure is important. And that
wayan failure will happen right away to be submitted to my operators as soon as possible. <p dir="ltr">The queue
jumpinglogic can not use the distributed transaction id? <p dir="ltr">On my logic, if a connection requests a shared
lockthat is already granted to another connection in the same distributed transaction it should be granted right
away...make sense?<div class="gmail_extra"><br /><div class="gmail_quote">Em 08/09/2016 4:15 PM, "Tom Lane" <<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>escreveu:<br type="attribution" /><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Lucas <<a
href="mailto:lucas75@gmail.com">lucas75@gmail.com</a>>writes:<br /> > I made a small modification in pg_dump to
preventparallel backup failures<br /> > due to exclusive lock requests made by other tasks.<br /><br /> > The
modificationI made take shared locks for each parallel backup worker<br /> > at the very beginning of the job. That
way,any other job that attempts to<br /> > acquire exclusive locks will wait for the backup to finish.<br /><br /> I
donot think this would eliminate the problem; all it's doing is making<br /> the window for trouble a bit narrower.
Also,it implies taking out many<br /> locks that would never be used, since no worker process will be touching<br />
allof the tables.<br /><br /> I think a real solution involves teaching the backend to allow a worker<br /> process to
acquirea lock as long as its master already has the same lock.<br /> There's already queue-jumping logic of that sort
inthe lock manager, but<br /> it doesn't fire because we don't see that there's a potential deadlock.<br /> What needs
tobe worked out, mostly, is how we can do that without<br /> creating security hazards (since the backend would have to
accepta<br /> command enabling this behavior from the client). Maybe it's good enough<br /> to insist that leader and
followerbe same user ID, or maybe not.<br /><br /> There's some related problems in parallel query, which AFAIK we just
have<br/> an ugly kluge solution for ATM. It'd be better if there were a clear<br /> model of when to allow a parallel
workerto get a lock out-of-turn.<br /><br /> regards, tom lane<br /></blockquote></div></div>