Where this "central log table will reside" - on third database ?
Seems to me you need to configure replication from one of the databases to the another of the data to be synchronized. Replication by itself is based on triggers. So why inventing your own home-grown replication API?
Or may be if you post more details, I can understand better what you are trying to do.
I need to invent my own replication APIs because the two data structures that are used in either of the databases are totally different. Therefore, I cannot simply replicate the data, I need to do some translation on the data before I attempt the update to the second database.
e.g. A system updates a row of a table in DB1. The trigger captures this event and calls an API which then determines which tables in DB2 need to be updated to maintain the integrity across the two tables. This API then updates DB2 with the update.
The log table would probably sit on DB2. This would be needed in order to determine when the update has been achieved.
Hope this helps clarify what I am aiming to do. I realise that the architecture of this solution is not great but we have very little choice over that.
Woosh I'm currently working on the same problem as you do! the only difference is that i'm trying to solve this problem using postgresql! maybe we can help each other! just contact me under email@example.com if you'd like to see my work!