| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Joachim Wieland <joe(at)mcknight(dot)de>, Greg Smith <greg(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Listen / Notify - what to do when the queue is full |
| Date: | 2010-01-20 00:24:19 |
| Message-ID: | 23390.1263947059@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-01-20 00:27:16 | Re: lock_timeout GUC patch |
| Previous Message | Jeff Davis | 2010-01-20 00:19:21 | Re: Listen / Notify - what to do when the queue is full |