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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Heikki Linnakangas"
Дата:
Сообщение: Re: HOT patch - version 14
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Lazy xid assignment V3