On 6/4/2010 10:44 AM, Greg Stark wrote:
On Fri, Jun 4, 2010 at 2:32 AM, Robert Haas <robertmh...@gmail.com> wrote:
I find the skeptical attitude on this thread altogether unwarranted.
Jan made his case and, at least IMHO, presented it pretty clearly.
Just to be clear I think the idea of exposing commit order is a
no-brainer. The specific interface is what I was questioning.
A function which takes a starting xid and a number of transactions to
return seems very tied to one particular application. I could easily
see other systems such as a multi-master system instead only wanting
to compare two transactions to find out which committed first. Or
non-replication applications where you have an LSN and want to know
whether a given transaction had committed by that time.
Read the proposal again. I mean the original mail that started this
tread. The function does NOT take an xid as argument.
Being able to compare two xid's against each other with respect to their
commit order is eventually useful. The serial number of the data set,
returned by the SRF as proposed, would perfectly satisfy that need. But
not the way you envision for multimaster. Multimaster would ask "did xid
X from server A commit before or after xid Y from server B?" That is a
question completely outside the scope of this proposal.
Please keep it real.
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
