Alvaro Herrera <[EMAIL PROTECTED]> writes:
> ITAGAKI Takahiro wrote:
>> Hmmm, my next question is whether we should use SHM_QUEUE or not in
>> new modules. The point deluded me when I wrote DSM and I wondered
>> the autovacuum-multiworkers patch uses SHM_QUEUE.
> Good question. I used SHM_QUEUE b
ITAGAKI Takahiro wrote:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > > I have a question about SHM_QUEUE. Why do we need this component?
> > It's a hangover from Berkeley days that no one has felt a need to remove
> > yet.
> >
> > > Then, can we replace SHM_QUEUE by a pointer-based double-linked
Tom Lane <[EMAIL PROTECTED]> wrote:
> > I have a question about SHM_QUEUE. Why do we need this component?
> It's a hangover from Berkeley days that no one has felt a need to remove yet.
>
> > Then, can we replace SHM_QUEUE by a pointer-based double-linked list?
> What exactly will you gain by it?
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> I have a question about SHM_QUEUE. Why do we need this component?
It's a hangover from Berkeley days that no one has felt a need to remove
yet. The convention back then was that shared memory might be mapped to
different addresses in different proces
Hello,
I have a question about SHM_QUEUE. Why do we need this component?
We've already made some modules under the assumption that the base offset
of shared memory is mapped to the same address for all processes.
See comment in freespace.h:
* Note: we handle pointers to these items as pointers,