Re: postgresql triggers - defining a global resource (java)
От | Alban Hertroys |
---|---|
Тема | Re: postgresql triggers - defining a global resource (java) |
Дата | |
Msg-id | 8AFCAE03-4F85-4549-A23F-9257616CD60F@gmail.com обсуждение исходный текст |
Ответ на | postgresql triggers - defining a global resource (java) (Aman Gupta <gupta.aman@gmail.com>) |
Ответы |
Re: postgresql triggers - defining a global resource (java)
|
Список | pgsql-general |
On 23 Dec 2011, at 14:33, Aman Gupta wrote: > The problem statement is mentioned here: > http://stackoverflow.com/questions/8615408/postgresql-triggers-defining-a-global-resource-java > > I am looking for the "best" solution to that problem. That would be using LISTEN/NOTIFY. If you perform RPCs directly from within your trigger, the transaction needs to wait until the RPC call succeeded, keepinglocks open much longer than necessary. That will block other transactions from touching these rows while the RPC isgoing on, among which will be autovacuum. For an implementation using LISTEN/NOTIFY you'd basically write a local daemon that's polling the database with LISTEN andperforms the necessary RPC when needed. It doesn't even need to be written in Java, you could use a language that canhandle NOTIFY as an event (although in the end it probably boils down to the same, but closer to kernel-level). If your PG is pre-9, then you'll want some mechanism that keeps a pool of pending data for RPC. In 9.0 and up you can sendrecord information along with NOTIFY. Alban Hertroys -- The scale of a problem often equals the size of an ego.
В списке pgsql-general по дате отправления: