Re: ANALYZE locks pg_listener in EXCLUSIVE for long time? - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: ANALYZE locks pg_listener in EXCLUSIVE for long time?
Date
Msg-id 20040503135945.GA28317@dcc.uchile.cl
Whole thread Raw
In response to Re: ANALYZE locks pg_listener in EXCLUSIVE for long time?  (Gavin Sherry <swm@linuxworld.com.au>)
Responses Re: ANALYZE locks pg_listener in EXCLUSIVE for long time?
List pgsql-hackers
On Mon, May 03, 2004 at 02:14:18PM +1000, Gavin Sherry wrote:

> It is implemented using shared memory. I got stuck when I considered the
> situation where we rung out of shared memory. Some emails in the archive
> suggested we just fire all listeners but I didn't like that.

Can this be kept in backend local memory and then sent to the other
backends at transaction commit?  If you run out of local memory you can
just spill to disk.  (With shared memory this seems pretty hard to do.)

I'm not sure how would one "send to the other backends."  Maybe write
another file on disk, one for each remote backend?  Surely this can be
done somehow.  I've heard that on linux-2.6 they are implementing "POSIX
message queues" (not sure what those are anyway); maybe we can do that
on platforms that support it, for performance.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"In a specialized industrial society, it would be a disaster
to have kids running around loose." (Paul Graham)


pgsql-hackers by date:

Previous
From: Claudio Natoli
Date:
Subject: Re: Fixed directory locations in installs
Next
From: Tom Lane
Date:
Subject: Re: ANALYZE locks pg_listener in EXCLUSIVE for long time?