Re: Lazy xid assignment V3
От | Florian G. Pflug |
---|---|
Тема | Re: Lazy xid assignment V3 |
Дата | |
Msg-id | 46DC2948.1090600@phlo.org обсуждение исходный текст |
Ответ на | Re: Lazy xid assignment V3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Lazy xid assignment V3
|
Список | pgsql-patches |
Tom Lane wrote: > "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. 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
В списке pgsql-patches по дате отправления: