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
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 |