Re: 2-phase commit

> > 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.