| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Massimo Dal Zotto <dz(at)cs(dot)unitn(dot)it> |
| Subject: | Re: [HACKERS] Anyone working on asynchronous NOTIFY reception? |
| Date: | 1998-04-17 14:46:16 |
| Message-ID: | 18817.892824376@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> The biggest problem is that if you have many clients listening on the same
> thing they are signaled at the same time and all of them try to access the
> pg_listener table for write. The result is that you have a lot of waits on
> the table and sometimes also deadlocks if you don't do things carefully.
Right, I recall seeing some things about that in the mailing list
archives (from you, no doubt?). I had the impression that async.c
had been changed to handle this better as of the current release.
Is there still a problem?
(Fortunately, I don't expect a *lot* of clients waiting on the same
table, but deadlock would still be very bad news...)
> From the Tcl side, a better solution would be to define a tcl event handler,
> like the standard Tcl filehandler, which would be invoked automatically by
> the Tk event loop or by tkwait if using pure Tcl.
I agree.
I don't have an immediate need for Tcl-based clients, so I was just
going to revise libpg and libpg++. Do you want to redo libpgtcl?
I'd probably get to that eventually, but splitting the work sounds
better :-).
I'll post something later today about what the extensions to the
libpg API should look like.
> I have also some new patches which try to reduce the notify overhead by
> avoiding unnecessary unlocks of the table. If you are interested I can
> post them.
Please do.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 1998-04-17 14:48:08 | Re: [HACKERS] drop table inside transactions |
| Previous Message | Byron Nikolaidis | 1998-04-17 14:40:34 | Re: [HACKERS] Re: [INTERFACES] Re: ODBC driver |