On 12/4/2010 1:38 PM, Simon Riggs wrote:
> On Fri, 2010-12-03 at 12:26 -0500, Christopher Browne wrote:
>>  === Commit timestamps ===
>>  * per Jan Wieck
>>  * Requires PostgreSQL extension
>>  * Eliminates need for periodic generation of SYNC events
>>  * Simplifies queries for searching for sl_log_* data
>>  * Enables carryover of commit times to subscribers
>
> It should be possible to do this using LISTEN/NOTIFY.
> Now we can pass a payload with the NOTIFY, we just need to pass the
> transaction id. That can be handled automatically by trigger.
>
> What we need is commit order, not commit timestamp, yes?
> NOTIFY happens in commit sequence. It doesn't provide the commit
> timestamp, but perhaps that can be provided by the LISTENer, if you
> really need it.
>

I'm not sure that we will ever get to a real consensus in the community, 
what such feature should actually look like. Maybe we should shift to 
something slightly different, following your suggestion of making the 
whole thing a hook.

The most generic hook would IMHO be to allow an on-commit trigger. It 
would fire as the last step in processing the deferred trigger queue. 
The permissions for creating such beast should be DB owner or superuser. 
That way, we offload the decision what to do in such a beast entirely to 
the user/developer and can simply say "if you don't like the 
implications, don't use it".

It may be the most expensive type of hook when actually used for 
something like recording the transaction commit order. But I would live 
with that as a first step. I've got the OK from my manager to spend time 
on this, so as soon as I find some (time), I'm going to do some hacking 
and then write up a proposal for PG hackers.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin