postgres-xc-developers Mailing List for Postgres-XC

OK I see.
So for the time being it may be better to let xc-watcher manage that.

Let's imagine that the node information is managed by catalog tables.
And let's also imagine that there is a way to inform in a short period time
all the pooler processes
that a node is down.

Could it be possible to do this management in catalog table instead of a
malloc'ed space?

> Memory context is a malloced memory. The only difference is that its
> managed by postgres. If your requirement is that modifications done by
> one process should be visible to other processes, then you must use
> shared memory (like what Suzuki-san is doing for xc-watcher).

On Thu, Feb 10, 2011 at 7:04 PM, Pavan Deolasee <pav...@gm...>wrote:

> Without reading very carefully what you are doing or want to do, here
> is a simple rule:
>
> A backend memory, irrespective of the context, is always local to the
> process. So any changes made by it will not be visible to other
> backends. If you want changes to be visible across backends, you must
> use shared memory.
>
> The memory context makes sense only for that backend. The transaction
> context is freed at the end of a transaction where as top memory
> context stays forever until the process exits or the memory is freed
> explicitly.
>


-- 
Michael Paquier
http://michaelpq.users.sourceforge.net