Re: Lazy xid assignment V3

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Lazy xid assignment V3
Date: 2007-09-03 15:33:28
Message-ID: 46DC2948.1090600@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Tom Lane wrote:
> "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.

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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2007-09-03 16:41:46 Re: Lazy xid assignment V3
Previous Message Heikki Linnakangas 2007-09-03 14:43:04 Re: HOT patch - version 14