Re: [HACKERS] Anyone working on asynchronous NOTIFY reception?
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Anyone working on asynchronous NOTIFY reception? |
Дата | |
Msg-id | 18817.892824376@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: [HACKERS] Anyone working on asynchronous NOTIFY reception?
|
Список | 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
В списке pgsql-hackers по дате отправления: