Re: ANALYZE locks pg_listener in EXCLUSIVE for long time?

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Philip Warner <pjw(at)rhyme(dot)com(dot)au>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ANALYZE locks pg_listener in EXCLUSIVE for long time?
Date: 2004-05-03 13:59:45
Message-ID: 20040503135945.GA28317@dcc.uchile.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-05-03 14:13:38 Re: ANALYZE locks pg_listener in EXCLUSIVE for long time?
Previous Message Claudio Natoli 2004-05-03 13:56:41 Re: Fixed directory locations in installs