Re: ALTER TABLE lock strength reduction patch is unsafe
От | Stephen Frost |
---|---|
Тема | Re: ALTER TABLE lock strength reduction patch is unsafe |
Дата | |
Msg-id | 20140304165022.GH12995@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: ALTER TABLE lock strength reduction patch is unsafe (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ALTER TABLE lock strength reduction patch is unsafe
|
Список | pgsql-hackers |
* Tom Lane (tgl@sss.pgh.pa.us) wrote: > Stephen Frost <sfrost@snowman.net> writes: > > I don't have too much of an issue with the above, but I would like to > > have us figure out a solution to the deadlock problem with parallel > > pg_dump. The issue arises when pg_dump gets an AccessShareLock and then > > another process attempts to acquire an AccessExclusiveLock, which then > > blocks, and then the pg_dump worker process tries to get its > > AccessShareLock- we end up not being able to make any progress on > > anything at that point. > > The original ASL was acquired by the pg_dump master, right? Yup. It goes through and gets ASLs on everything first. > > One suggestion that was discussed at PGConf.EU was having processes > > which share the same snapshot (the pg_dump master and worker processes) > > able to either share the same locks or at least be able to "jump" the > > lock queue (that is, the worker process wouldn't have to wait being the > > AEL to get an ASL, since the ASL was already aquired for the snapshot > > which was exported and shared with it). > > Yeah, it seems like we need lock export not only snapshot export to make > this work nicely. But that sounds orthogonal to the issues being > discussed in this thread. Indeed, just figured I'd mention it since we're talking about pg_dump-related locking. Thanks, Stephen
В списке pgsql-hackers по дате отправления: