Simon Riggs <simon at 2ndQuadrant.com> writes:
> On Mon, 2010-12-06 at 15:25 -0500, Christopher Browne wrote:
>> Steve Singer <ssinger at ca.afilias.info> writes:
>> > On 10-12-04 01: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 happens if the server crashes before the process listening does
>> > what it needs to?  I don't think the notification queue gets
>> > persisted.
>> 
>> Not anymore, no, and that could well present a problem.
>
> Yes, if server crashes, many things will be lost.
>
> It seems likely to me that there will few, if any, transactions for
> which we don't know the commit timestamp. All of the current
> transactions will be lost.
>
> Do we really need the timestamp for every single transaction? Surely we
> can make a good guess from the transactions before and after.

It would be a slick added feature to actually have the timestamp for
every single transaction.  That being captured, and carried over to
replicas, it would be possible for triggers run on subscribers to access
the actual commit time.  (Just requires adding a function
get_commit_timestamp().)

That could add usefully to the data available.

That's not necessarily reason to require per-transaction timestamps, but
it would be nice to have...
-- 
output = reverse("ofni.sailifa" "@" "enworbbc")
Christopher Browne
"Bother,"  said Pooh,  "Eeyore, ready  two photon  torpedoes  and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"