Excerpts from Gavin Flower's message of mar ago 21 16:51:57 -0400 2012:
> On 22/08/12 02:16, Kevin Grittner wrote:
> > So, if you want to allow serializable temporal queries, the timing
> > of a read-write serializable transaction can't be locked down until
> > all overlapping read-write serializable transactions complete; and
> > the apparent order of execution must be based on read-write
> > conflicts, which are tracked within SSI. I think that if we can
> > generate a list of committed transactions in order based on this
> > logic, it could feed into replication system -- hot standby as well
> > as trigger-based systems. I think we could generate snapshots which
> > exclude the transactions for which the order of execution has not
> > yet been determined, and avoid the delays involved in other possible
> > solutions.
> If there is a very long running transaction, say 1 hour, then all (or
> just some? - depending) transactions that nominally start and finish
> within that time, can not have definitive start times until the very
> long running transaction finishes, even if they are successfully committed?
>
> So if someone looks at the audit log they might not see all the
> transactions they expect to see.
I think there would need to be a way to also list transactions which are
"in progress" -- this would include not only live transactions, but also
all those transactions that have actually committed but are not yet
listed as committed because their position in the commit sequence has
not been determined.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
