Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
От | Masahiko Sawada |
---|---|
Тема | Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager |
Дата | |
Msg-id | CAD21AoAfuzsdp8f3QRGCJdac1bYd=A_omwtiW=taVTBSCGcOPw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
|
Список | pgsql-hackers |
On Wed, May 17, 2017 at 1:30 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Sat, May 13, 2017 at 7:27 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> On Fri, May 12, 2017 at 9:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Robert Haas <robertmhaas@gmail.com> writes: >>>> On Wed, May 10, 2017 at 8:39 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote: >>>>> ... I'd like to propose to change relation >>>>> extension lock management so that it works using LWLock instead. >>> >>>> That's not a good idea because it'll make the code that executes while >>>> holding that lock noninterruptible. >>> >>> Is that really a problem? We typically only hold it over one kernel call, >>> which ought to be noninterruptible anyway. >> >> During parallel bulk load operations, I think we hold it over multiple >> kernel calls. > > We do. Also, RelationGetNumberOfBlocks() is not necessarily only one > kernel call, no? Nor is vm_extend. Yeah, these functions could call more than one kernel calls while holding extension lock. > Also, it's not just the backend doing the filesystem operation that's > non-interruptible, but also any waiters, right? > > Maybe this isn't a big problem, but it does seem to be that it would > be better to avoid it if we can. > I agree to change it to be interruptible for more safety. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: