Re: dynamically allocating chunks from shared memory

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Markus Wanner <markus(at)bluegap(dot)ch>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dynamically allocating chunks from shared memory
Date: 2010-07-22 18:31:41
Message-ID: 1279823238-sup-6350@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Excerpts from Markus Wanner's message of jue jul 22 08:49:29 -0400 2010:

> Of course, as mentioned in the bgworker patch, this could be done
> differently. Using solely shared memory, or maybe SLRU to store change
> sets. However, I certainly like the abstraction and guarantees such a
> message passing system provides. It makes things easier to reason about,
> IMO.

FWIW I don't think you should be thinking in "replacing imessages with
SLRU". I rather think you should be thinking in how can you implement
the imessages API on top of SLRU. So as far as the coordinator and
background worker are concerned, there wouldn't be any difference --
they keep using the same API they are using today.

Also let me repeat my earlier comment about imessages being more similar
to multixact than to notify. The content of each multixact entry is
just an arbitrary amount of bytes. If imessages are numbered from a
monotonically increasing sequence, it should be possible to use a very
similar technique, and perhaps you should be able to reduce locking
requirements as well (write messages with only a shared lock, after
you've determined and reserved the area you're going to write).

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-07-22 18:51:13 Re: CommitFest 2010-07 week one progress report
Previous Message Kevin Grittner 2010-07-22 18:09:32 CommitFest 2010-07 week one progress report