Re: 2-phase commit
От | Rod Taylor |
---|---|
Тема | Re: 2-phase commit |
Дата | |
Msg-id | 1064778892.21931.55.camel@jester обсуждение исходный текст |
Ответ на | Re: 2-phase commit (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
> > Actually, all that's really necessary is the ability to call a stored > > procedure when some event occurs. The stored procedure can take it from > > there, and since it can be written in C it can do anything the postgres > > user can do (for good or for ill, of course). > > But the postmaster doesn't connect to any database, and in a serious > failure, might not be able to start one. In the event of a catastrophic, the 'nothing is running' scenario is one standard monitoring software should pick up on that easily enough. One that PostgreSQL cannot help with anyway (normally this is admin error). Something simple much like pg_locks with transaction state (idle, waiting on local lock, waiting on 3rd party, etc.), time transaction started, time of last status change would be plenty. The monitor software folks (Big Brother, etc. etc.) can write jobs to query those elements and create the appropriate SNMP events when say waiting on 3rd party for > N minutes (log at 1, trouble ticket at 2, SysAdmin page at 5, escalate to VP Pager at 20 minutes or whatever corporate policy is). An alternative is to package an SNMP daemon (much like the stats daemon) into the backend to generate SNMP events -- but I think this is overkill if views are available.
В списке pgsql-hackers по дате отправления: