Re: Lazy xid assignment V3

"Heikki Linnakangas" <heikki(at)enterprisedb(dot)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