Another approach I've been thinking about is to allow anyone that knows the (user-supplied) global transaction identifier to finish the transaction, and hide the gids of running transactions from regular users. That way, the gid acts as a secret token that's only known by the transaction manager, much like the cancel key.
Personally I prefer the last. It should be infeasible to crack as long as the gid is long enough (e.g. sufficiently random 128bit value or more) and the channel between the TM and Postgres is secure.
So it is possible for a user connected to the DB to send random commit or cancel commands, just in case she happens to hit a valid GID?
It is not essentially different from someone trying to bruteforce a password. A 128bit value like a random GUID is as strong as a 16 char password comprising ASCII 0-255 characters. And I would argue that this is _not_ security through obscurity. Security through obscurity is relying on unpublished methods/algorithms. This is not.
But I understand that everybody seems to be against this idea.
-- dave
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
