Re: shared memory message queues

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: shared memory message queues
Дата
Msg-id CA+TgmoadtKyK_UodzKMKLw7ypn+4WCKzX8tRs-MhY-b+aSOBVQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: shared memory message queues  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: shared memory message queues  (Thom Brown <thom@linux.com>)
Re: shared memory message queues  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On Mon, Dec 23, 2013 at 12:46 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Oh, dear.  That's rather embarrassing.
>
> Incremental (incremental-shm-mq.patch) and full (shm-mq-v3.patch)
> patches attached.

OK, I have pushed the patches in this stack.  I'm not sure we quite
concluded the review back-and-forth but nobody really seems to have
had serious objections to this line of attack, other than wanting some
more comments which I have added.  I don't doubt that there will be
more things to tweak and tune here, and a whole lot more stuff that
needs to be built using this infrastructure, but I don't think the
code that's here is going to get better for remaining outside the tree
longer.

I decided not to change the dsm_toc patch to use functions instead of
macros as Andres suggested; the struct definition would still have
needed to be public, so any change would still need a recompile, at
least if the size of the struct changed.  It could be changed to work
with a palloc'd chunk, but then you need to worry about
context-lifespan memory leaks and it so didn't seem worth it.  I can't
imagine this having a lot of churn, anyway.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Следующее
От: Tom Lane
Дата:
Сообщение: Re: extension_control_path