On Sat, Dec 12, 2015 at 1:17 PM, and...@anarazel.de <and...@anarazel.de> wrote: > On 2015-11-15 16:24:24 -0500, Robert Haas wrote: >> I think what we should do about the buffer locks is polish up this >> patch and get it applied: >> >> http://www.postgresql.org/message-id/20150907175909.gd5...@alap3.anarazel.de >> >> I think it needs to be adapted to use predefined constants for the >> tranche IDs instead of hardcoded values, maybe based on the attached >> tranche-constants.patch. > > 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. 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). > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
