| From: | Andres Freund <andres(at)anarazel(dot)de> | 
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> | 
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: Separating Buffer LWlocks | 
| Date: | 2015-09-08 18:35:38 | 
| Message-ID: | 20150908183538.GK5084@alap3.anarazel.de | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On 2015-09-08 14:31:53 -0400, Robert Haas wrote:
> On Tue, Sep 8, 2015 at 2:19 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2015-09-08 14:15:32 -0400, Robert Haas wrote:
> >> We could do that, but I'm not sure just calling LWLockNewTrancheId()
> >> for all of the tranches would be so bad either.
> >
> > To me that seems either fragile or annoying to use. If all backends call
> > LWLockNewTrancheId() we need to a be sure the callbacks are always going
> > to be called in the same order.
> 
> How is that going to work?  The counter is in shared memory.
Oh, right. It's just the tranche definitions themselves that live in
backend private memory.
> > Otherwise everyone needs to store the
> > tranche in shared memory (like xlog.c now does) which I find to be a
> > rather annoying requirement.
> 
> Yes, everyone would need to do that.  If that's too annoying to live
> with, then we can adopt your suggestion.
I think having to add a separate ShmemInitStruct() just to be able to
store the tranche id falls under too annoying.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Petr Jelinek | 2015-09-08 18:40:42 | Re: Horizontal scalability/sharding | 
| Previous Message | Andres Freund | 2015-09-08 18:33:56 | Re: Improving test coverage of extensions with pg_dump |