Re: Lazy xid assignment V3 - Mailing list pgsql-patches

From Florian G. Pflug
Subject Re: Lazy xid assignment V3
Date
Msg-id 46DC2948.1090600@phlo.org
Whole thread Raw
In response to Re: Lazy xid assignment V3  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Lazy xid assignment V3  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: "Heikki Linnakangas"
Date:
Subject: Re: HOT patch - version 14
Next
From: Tom Lane
Date:
Subject: Re: Lazy xid assignment V3