From: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | 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 04:14:18 |
Message-ID: | Pine.LNX.4.58.0405031411001.3582@linuxworld.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 2 May 2004, Bruce Momjian wrote:
> Tom Lane wrote:
> > Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> > > Does this mean that ANALYZE will take an exclusive lock on pg_listener
> > > until the ANALYZE finishes? Or is there some other cause?
> >
> > ANALYZE does not take an exclusive lock on anything. However, the
> > async.c functions want AccessExclusiveLock on pg_listener, so they
> > quite possibly would get blocked by ANALYZE's not-so-exclusive lock.
> >
> > Possibly we could reduce the strength of the lock taken by the async.c
> > functions ... I haven't thought hard about it. The long-term answer is
> > certainly a wholesale rewrite of the listen/notify mechanism.
>
> Gavin was working on it a while ago but I am not sure how far he got.
Its basically written.
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.
What I was considering was that when someone issues a NOTIFY, we reserve a
slot for the NOTIFY (plus a message, which is why I originally looked at
the problem) in shared memory. At the end of the transaction, we update a
flag to say that the transaction successed or we remove it if we've
aborted.
Does anyone else have any thoughts about it?
Gavin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-05-03 04:21:18 | Re: ANALYZE locks pg_listener in EXCLUSIVE for long time? |
Previous Message | sdv mailer | 2004-05-03 04:11:27 | PostgreSQL pre-fork speedup |