From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Do we need a ShmList implementation? |
Date: | 2010-09-20 16:20:22 |
Message-ID: | 1284999622.1733.5756.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2010-09-20 at 18:37 +0300, Heikki Linnakangas wrote:
> > SHM_QUEUE objects provide the infrastructure for maintaining a
> > shared memory linked list, but they don't do anything about the
> > allocation and release of the space for the objects. So it occurs
> > to me that I'm using an HTAB for this collection because it provides
> > the infrastructure for managing the memory for the collection,
> > rather than because I need hash lookup. :-( It works, but that
> > hardly seems optimal.
>
> > Have I missed something we already have which could meet that need?
>
> Well, we generally try to avoid dynamic structures in shared memory,
> because shared memory can't be resized. So, you'd typically use an array
> with a fixed number of elements. One could even argue that we
> specifically *don't* want to have the kind of infrastructure you
> propose, to discourage people from writing patches that need dynamic
> shmem structures.
My understanding is that we used to have that and it was removed for the
reasons Heikki states. There are still vestigial bits still in code.
Not exactly impressed with the SHM_QUEUE stuff though, so I appreciate
the sentiment that Kevin expresses.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Wong | 2010-09-20 16:24:37 | Re: compile/install of git |
Previous Message | Tom Lane | 2010-09-20 16:17:41 | Re: libpq changes for synchronous replication |