Re: [PATCH] Refactoring of LWLock tranches
От | andres@anarazel.de |
---|---|
Тема | Re: [PATCH] Refactoring of LWLock tranches |
Дата | |
Msg-id | 20151213113534.GV14789@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: [PATCH] Refactoring of LWLock tranches (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PATCH] Refactoring of LWLock tranches
Re: [PATCH] Refactoring of LWLock tranches |
Список | pgsql-hackers |
On 2015-12-12 21:15:52 -0500, Robert Haas wrote: > On Sat, Dec 12, 2015 at 1:17 PM, andres@anarazel.de <andres@anarazel.de> wrote: > > Here's two patches doing that. The first is an adaption of your > > constants patch, using an enum and also converting xlog.c's locks. The > > second is the separation into distinct tranches. > > Personally, I prefer the #define approach to the enum, but I can live > with doing it this way. I think the lack needing to adjust the 'last defined' var is worth it... > Other than that, I think these patches look > good, although if it's OK with you I would like to make a pass over > the comments and the commit messages which seem to me that they could > benefit from a bit of editing (but not much substantive change). Sounds good to me. You'll then commit that? > > One thing to call out is that an "oversized" s_lock can now make > > BufferDesc exceed 64 bytes, right now that's just the case when it's > > larger than 4 bytes. I'm not sure if that's cause for real concern, > > given that it's not very concurrent or ancient platforms where that's > > the case. > > http://archives.postgresql.org/message-id/20150915020625.GI9666%40alap3.anarazel.de > > would alleviate that concern again, as it collapses flags, usage_count, > > buf_hdr_lock and refcount into one 32 bit int... > > I don't think that would be worth worrying about even if we didn't > have a plan in mind that would make it go away again, and even less so > given that we do have such a plan. Ok cool. I'm not particularly concerned either, just didn't want to slip that in without having it called out. Andres
В списке pgsql-hackers по дате отправления: