"Heikki Linnakangas" <heikki@enterprisedb.com> 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. > 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. >> Since we didn't really reach an agreement on how xid_age should behave, >> I've reverted it back to the original version. So with this patch, >> xid_age will just force assignment of a xid. > Sounds OK to me. It's not going to consume any more xids than it does > now, and I don't think xid_age is called very often. What's it for > anyway? To write scripts to run VACUUM before xid wrap-around? Yeah. I think xid_age is really just a historical curiosity anyway as of 8.2 --- there's hardly any real use-case for it. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

"Heikki Linnakangas" <heikki@enterprisedb.com> writes: > Yeah. If we did want to do something more, we could acquire the lock on > vid conditionally, and use another vid if acquiring the lock fails. But > I don't think it's necessary. I was thinking more along the lines of looking through the ProcArray at backend startup to ensure the sessionID we've chosen is unique, and choosing another one if not. But this would expend cycles with the ProcArray locked, for something that seems exceedingly unlikely to happen, regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend