Re: Listen / Notify - what to do when the queue is full - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Listen / Notify - what to do when the queue is full
Date
Msg-id 23390.1263947059@sss.pgh.pa.us
Whole thread Raw
In response to Re: Listen / Notify - what to do when the queue is full  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Listen / Notify - what to do when the queue is full  (Jeff Davis <pgsql@j-davis.com>)
Re: Listen / Notify - what to do when the queue is full  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> I was also worried about holding multiple LWLocks at once -- is such
> practice generally avoided in the rest of the code?

It's allowed but remember that there is no deadlock detection in lwlock.c.
You must be very certain that there is only one possible order in which
such locks could be taken.  Interactions with heavyweight locks would be
bad news as well.

> It appears that the locks are only taken when LISTEN or NOTIFY is
> involved.

On the whole it might be better if a heavyweight lock were used,
such that it'll automatically clean up after commit.  (I'm still
wondering if we couldn't do without the lock altogether though.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Listen / Notify - what to do when the queue is full
Next
From: Robert Haas
Date:
Subject: Re: lock_timeout GUC patch