Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
Should there be new a log_line_prefix percent code for virtual
transaction ids? Or should we change the meaning of %x to be virtual
transaction id instead of the real one.
I think the latter should be sufficient, especially if we also are showing
vxid in pg_locks and pg_stat_activity.
Hm.. Wouldn't that kind of defeat the idea of a log, if you need the
output of pg_locks to interpret it? Maybe we should just show both
values for %x? Or just the xid if it's set, and the vid otherwise?
BTW, my current patch doesn't show the vid in pg_stat_activity. I
initially wanted to add because, because I believed that the xid
is also shown in pg_stat_activity. But I then realized that the
xid actually *isn't* shown, and the all the other values shown in
pg_stat_activity are directly pulled out of the stats collector.
So it seems quite messy and inconsistent to add the vid.
What the worst thing that happens if two sessions are assigned the same
session id? Should be infrequent, but not impossible if you have some
very long-lived connections and other clients connecting/disconnecting
all the time.
I think this'll be all right. The only operations we actually do on
vxids is equality comparison. Even if you had a session that was 4
billion new-connections old, it should also have a pretty darn high
localvxid counter, and so a new session coming in and starting its
counter at 0 is highly unlikely to conflict. It's not impossible,
I guess, but the odds against seem so high that it's not worth adding
code to prevent it.
Even in the case of a conflict, two transactions still wouldn't be
running with the same vid. Rather, the second one would block until
the first exits, because we hold an ExclusiveLock on the vid.
Still, I overlooked the possibility of this, and it does seem a bit
ugly. Maybe we ought to use MyBackendId to disambiguate this? All it
would take would be another field backendId in VirtualTransactionId.
greetings, Florian Pflug
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
